--- 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" "Python2 HTTP Status Constant": "httplib.NOT_MODIFIED" "Python3+ HTTP Status Constant": "http.client.NOT_MODIFIED" "Python3.5+ HTTP Status Constant": "http.HTTPStatus.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]: [2]: