13.2.6 Disambiguating Multiple Responses
Connected: An Internet Encyclopedia
13.2.6 Disambiguating Multiple Responses
Up:
Connected: An Internet Encyclopedia
Up:
Requests For Comments
Up:
RFC 2068
Up:
13 Caching in HTTP
Up:
13.2 Expiration Model
Prev: 13.2.5 Disambiguating Expiration Values
Next: 13.3 Validation Model
13.2.6 Disambiguating Multiple Responses
13.2.6 Disambiguating Multiple Responses
Because a client may be receiving responses via multiple paths, so
that some responses flow through one set of caches and other
responses flow through a different set of caches, a client may
receive responses in an order different from that in which the origin
server sent them. We would like the client to use the most recently
generated response, even if older responses are still apparently
fresh.
Neither the entity tag nor the expiration value can impose an
ordering on responses, since it is possible that a later response
intentionally carries an earlier expiration time. However, the
HTTP/1.1 specification requires the transmission of Date headers on
every response, and the Date values are ordered to a granularity of
one second.
When a client tries to revalidate a cache entry, and the response it
receives contains a Date header that appears to be older than the one
for the existing entry, then the client SHOULD repeat the request
unconditionally, and include
Cache-Control: max-age=0
to force any intermediate caches to validate their copies directly
with the origin server, or
Cache-Control: no-cache
to force any intermediate caches to obtain a new copy from the origin
server.
If the Date values are equal, then the client may use either response
(or may, if it is being extremely prudent, request a new response).
Servers MUST NOT depend on clients being able to choose
deterministically between responses generated during the same second,
if their expiration times overlap.
Next: 13.3 Validation Model
Connected: An Internet Encyclopedia
13.2.6 Disambiguating Multiple Responses
|