13.4 Response Cachability

   Unless specifically constrained by a Cache-Control (section 14.9)
   directive, a caching system may always store a successful response
   (see section 13.8) as a cache entry, may return it without validation
   if it is fresh, and may return it after successful validation. If



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


   there is neither a cache validator nor an explicit expiration time
   associated with a response, we do not expect it to be cached, but
   certain caches may violate this expectation (for example, when little
   or no network connectivity is available). A client can usually detect
   that such a response was taken from a cache by comparing the Date
   header to the current time.

     Note that some HTTP/1.0 caches are known to violate this
     expectation without providing any Warning.

   However, in some cases it may be inappropriate for a cache to retain
   an entity, or to return it in response to a subsequent request. This
   may be because absolute semantic transparency is deemed necessary by
   the service author, or because of security or privacy considerations.
   Certain Cache-Control directives are therefore provided so that the
   server can indicate that certain resource entities, or portions
   thereof, may not be cached regardless of other considerations.

   Note that section 14.8 normally prevents a shared cache from saving
   and returning a response to a previous request if that request
   included an Authorization header.

   A response received with a status code of 200, 203, 206, 300, 301 or
   410 may be stored by a cache and used in reply to a subsequent
   request, subject to the expiration mechanism, unless a Cache-Control
   directive prohibits caching. However, a cache that does not support
   the Range and Content-Range headers MUST NOT cache 206 (Partial
   Content) responses.

   A response received with any other status code MUST NOT be returned
   in a reply to a subsequent request unless there are Cache-Control
   directives or another header(s) that explicitly allow it. For
   example, these include the following: an Expires header (section
   14.21); a "max-age", "must-revalidate", "proxy-revalidate", "public"
   or "private" Cache-Control directive (section 14.9).

13.5 Constructing Responses From Caches

   The purpose of an HTTP cache is to store information received in
   response to requests, for use in responding to future requests. In
   many cases, a cache simply returns the appropriate parts of a
   response to the requester. However, if the cache holds a cache entry
   based on a previous response, it may have to combine parts of a new
   response with what is held in the cache entry.







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


13.5.1 End-to-end and Hop-by-hop Headers

   For the purpose of defining the behavior of caches and non-caching
   proxies, we divide HTTP headers into two categories:

  o  End-to-end headers, which must be transmitted to the
     ultimate recipient of a request or response. End-to-end
     headers in responses must be stored as part of a cache entry
     and transmitted in any response formed from a cache entry.
  o  Hop-by-hop headers, which are meaningful only for a single
     transport-level connection, and are not stored by caches or
     forwarded by proxies.

   The following HTTP/1.1 headers are hop-by-hop headers:

     o  Connection
     o  Keep-Alive
     o  Public
     o  Proxy-Authenticate
     o  Transfer-Encoding
     o  Upgrade

   All other headers defined by HTTP/1.1 are end-to-end headers.

   Hop-by-hop headers introduced in future versions of HTTP MUST be
   listed in a Connection header, as described in section 14.10.