httpstatuses/contents/codes/304.md

---
set: 3
code: 304
title: Not Modified
references:
    "Rails HTTP Status Symbol": ":not_modified"
    "Go HTTP Status Constant": "http.StatusNotModified"
    "Symfony HTTP Status Constant": "Response::HTTP_NOT_MODIFIED"
---

A conditional GET or HEAD request has been received and would have resulted in a
[200 OK](/200) response if it were not for the fact that the condition evaluated
to false.

In other words, there is no need for the server to transfer a representation of
the target resource because the request indicates that the client, which made
the request conditional, already has a valid representation; the server is
therefore redirecting the client to make use of that stored representation as if
it were the payload of a [200 OK](/200) response.

The server generating a 304 response MUST generate any of the following header
fields that would have been sent in a [200 OK](/200) response to the same
request: Cache-Control, Content-Location, Date, ETag, Expires, and Vary.

Since the goal of a 304 response is to minimize information transfer when the
recipient already has one or more cached representations, a sender SHOULD NOT
generate representation metadata other than the above listed fields unless said
metadata exists for the purpose of guiding cache updates (e.g., Last-Modified
might be useful if the response does not have an ETag field).

Requirements on a cache that receives a 304 response are defined in
[Section 4.3.4 of RFC7234][2]. If the conditional request originated with an
outbound client, such as a user agent with its own cache sending a conditional
GET to a shared proxy, then the proxy SHOULD forward the 304 response to that
client.

A 304 response cannot contain a message-body; it is always terminated by the
first empty line after the header fields.

---

* Source: [RFC7232 Section 4.1][1]

[1]: <http://tools.ietf.org/html/rfc7232#section-4.1>
[2]: <http://tools.ietf.org/html/rfc7234#section-4.3.4>