13.1.1 Cache Correctness

   A correct cache MUST respond to a request with the most up-to-date
   response held by the cache that is appropriate to the request (see
   sections 13.2.5, 13.2.6, and 13.12) which meets one of the following
   conditions:

  1. It has been checked for equivalence with what the origin server
     would have returned by revalidating the response with the origin
     server (section 13.3);

  2. It is "fresh enough" (see section 13.2). In the default case, this
     means it meets the least restrictive freshness requirement of the
     client, server, and cache (see section 14.9); if the origin server
     so specifies, it is the freshness requirement of the origin server
     alone.

  3. It includes a warning if the freshness demand of the client or the
     origin server is violated (see section 13.1.5 and 14.45).

  4. It is an appropriate 304 (Not Modified), 305 (Proxy Redirect), or
     error (4xx or 5xx) response message.

   If the cache can not communicate with the origin server, then a
   correct cache SHOULD respond as above if the response can be
   correctly served from the cache; if not it MUST return an error or



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


   warning indicating that there was a communication failure.

   If a cache receives a response (either an entire response, or a 304
   (Not Modified) response) that it would normally forward to the
   requesting client, and the received response is no longer fresh, the
   cache SHOULD forward it to the requesting client without adding a new
   Warning (but without removing any existing Warning headers). A cache
   SHOULD NOT attempt to revalidate a response simply because that
   response became stale in transit; this might lead to an infinite
   loop. An user agent that receives a stale response without a Warning
   MAY display a warning indication to the user.

13.1.2 Warnings

   Whenever a cache returns a response that is neither first-hand nor
   "fresh enough" (in the sense of condition 2 in section 13.1.1), it
   must attach a warning to that effect, using a Warning response-
   header. This warning allows clients to take appropriate action.

   Warnings may be used for other purposes, both cache-related and
   otherwise. The use of a warning, rather than an error status code,
   distinguish these responses from true failures.

   Warnings are always cachable, because they never weaken the
   transparency of a response. This means that warnings can be passed to
   HTTP/1.0 caches without danger; such caches will simply pass the
   warning along as an entity-header in the response.

   Warnings are assigned numbers between 0 and 99. This specification
   defines the code numbers and meanings of each currently assigned
   warnings, allowing a client or cache to take automated action in some
   (but not all) cases.

   Warnings also carry a warning text. The text may be in any
   appropriate natural language (perhaps based on the client's Accept
   headers), and include an optional indication of what character set is
   used.

   Multiple warnings may be attached to a response (either by the origin
   server or by a cache), including multiple warnings with the same code
   number. For example, a server may provide the same warning with texts
   in both English and Basque.

   When multiple warnings are attached to a response, it may not be
   practical or reasonable to display all of them to the user. This
   version of HTTP does not specify strict priority rules for deciding
   which warnings to display and in what order, but does suggest some
   heuristics.



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


   The Warning header and the currently defined warnings are described
   in section 14.45.

13.1.3 Cache-control Mechanisms

   The basic cache mechanisms in HTTP/1.1 (server-specified expiration
   times and validators) are implicit directives to caches. In some
   cases, a server or client may need to provide explicit directives to
   the HTTP caches. We use the Cache-Control header for this purpose.

   The Cache-Control header allows a client or server to transmit a
   variety of directives in either requests or responses. These
   directives typically override the default caching algorithms. As a
   general rule, if there is any apparent conflict between header
   values, the most restrictive interpretation should be applied (that
   is, the one that is most likely to preserve semantic transparency).
   However, in some cases, Cache-Control directives are explicitly
   specified as weakening the approximation of semantic transparency
   (for example, "max-stale" or "public").

   The Cache-Control directives are described in detail in section 14.9.