Created
March 30, 2012 12:39
-
-
Save karlcow/2251225 to your computer and use it in GitHub Desktop.
Prose for HTTP 304
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
4.1. 304 Not Modified | |
The 304 status code indicates that a conditional GET request has been | |
received and would have resulted in a 200 (OK) response if it were | |
not for the fact that the condition has evaluated to false. In other | |
words, there is no need for the server to transfer a representation | |
of the target resource because the client's request indicates that it | |
already has a valid representation, as indicated by the 304 response | |
header fields, and is therefore redirecting the client to make use of | |
that stored representation as if it were the payload of a 200 | |
response. The 304 response MUST NOT contain a message-body, and thus | |
is always terminated by the first empty line after the header fields. | |
A 304 response MUST include a Date header field (Section 10.2 of | |
[Part2]) unless the origin server does not have a clock that can | |
provide a reasonable approximation of the current time. If a 200 | |
response to the same request would have included any of the header | |
fields Cache-Control, Content-Location, ETag, Expires, or Vary, then | |
those same header fields MUST be sent in a 304 response. | |
Since the goal of a 304 response is to minimize information transfer | |
when the recipient already has one or more cached representations, | |
the response SHOULD NOT include representation metadata other than | |
the above listed fields unless said metadata exists for the purpose | |
of guiding cache updates (e.g., future HTTP extensions). | |
If the recipient of a 304 response does not have a cached | |
representation corresponding to the entity-tag indicated by the 304 | |
response, then the recipient MUST NOT use the 304 to update its own | |
cache. If this 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 304 response MAY be forwarded to the | |
outbound client. Otherwise, the recipient MUST disregard the 304 | |
response and repeat the request without any preconditions. | |
If a cache uses a received 304 response to update a cache entry, the | |
cache MUST update the entry to reflect any new field values given in | |
the response. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment