13.6 Caching Negotiated Responses

   Use of server-driven content negotiation (section 12), as indicated
   by the presence of a Vary header field in a response, alters the
   conditions and procedure by which a cache can use the response for
   subsequent requests.

   A server MUST use the Vary header field (section 14.43) to inform a
   cache of what header field dimensions are used to select among
   multiple representations of a cachable response. A cache may use the
   selected representation (the entity included with that particular
   response) for replying to subsequent requests on that resource only
   when the subsequent requests have the same or equivalent values for
   all header fields specified in the Vary response-header. Requests
   with a different value for one or more of those header fields would
   be forwarded toward the origin server.

   If an entity tag was assigned to the representation, the forwarded
   request SHOULD be conditional and include the entity tags in an If-
   None-Match header field from all its cache entries for the Request-
   URI. This conveys to the server the set of entities currently held by
   the cache, so that if any one of these entities matches the requested
   entity, the server can use the ETag header in its 304 (Not Modified)
   response to tell the cache which entry is appropriate. If the
   entity-tag of the new response matches that of an existing entry, the



Fielding, et. al.           Standards Track                    [Page 90]

RFC 2068                        HTTP/1.1                    January 1997


   new response SHOULD be used to update the header fields of the
   existing entry, and the result MUST be returned to the client.

   The Vary header field may also inform the cache that the
   representation was selected using criteria not limited to the
   request-headers; in this case, a cache MUST NOT use the response in a
   reply to a subsequent request unless the cache relays the new request
   to the origin server in a conditional request and the server responds
   with 304 (Not Modified), including an entity tag or Content-Location
   that indicates which entity should be used.

   If any of the existing cache entries contains only partial content
   for the associated entity, its entity-tag SHOULD NOT be included in
   the If-None-Match header unless the request is for a range that would
   be fully satisfied by that entry.

   If a cache receives a successful response whose Content-Location
   field matches that of an existing cache entry for the same Request-
   URI, whose entity-tag differs from that of the existing entry, and
   whose Date is more recent than that of the existing entry, the
   existing entry SHOULD NOT be returned in response to future requests,
   and should be deleted from the cache.

13.7 Shared and Non-Shared Caches

   For reasons of security and privacy, it is necessary to make a
   distinction between "shared" and "non-shared" caches. A non-shared
   cache is one that is accessible only to a single user. Accessibility
   in this case SHOULD be enforced by appropriate security mechanisms.
   All other caches are considered to be "shared." Other sections of
   this specification place certain constraints on the operation of
   shared caches in order to prevent loss of privacy or failure of
   access controls.

13.8 Errors or Incomplete Response Cache Behavior

   A cache that receives an incomplete response (for example, with fewer
   bytes of data than specified in a Content-Length header) may store
   the response. However, the cache MUST treat this as a partial
   response.  Partial responses may be combined as described in section
   13.5.4; the result might be a full response or might still be
   partial. A cache MUST NOT return a partial response to a client
   without explicitly marking it as such, using the 206 (Partial
   Content) status code. A cache MUST NOT return a partial response
   using a status code of 200 (OK).

   If a cache receives a 5xx response while attempting to revalidate an
   entry, it may either forward this response to the requesting client,



Fielding, et. al.           Standards Track                    [Page 91]

RFC 2068                        HTTP/1.1                    January 1997


   or act as if the server failed to respond. In the latter case, it MAY
   return a previously received response unless the cached entry
   includes the "must-revalidate" Cache-Control directive (see section
   14.9).

13.9 Side Effects of GET and HEAD

   Unless the origin server explicitly prohibits the caching of their
   responses, the application of GET and HEAD methods to any resources
   SHOULD NOT have side effects that would lead to erroneous behavior if
   these responses are taken from a cache. They may still have side
   effects, but a cache is not required to consider such side effects in
   its caching decisions. Caches are always expected to observe an
   origin server's explicit restrictions on caching.

   We note one exception to this rule: since some applications have
   traditionally used GETs and HEADs with query URLs (those containing a
   "?" in the rel_path part) to perform operations with significant side
   effects, caches MUST NOT treat responses to such URLs as fresh unless
   the server provides an explicit expiration time. This specifically
   means that responses from HTTP/1.0 servers for such URIs should not
   be taken from a cache. See section 9.1.1 for related information.