RFC 2068                        HTTP/1.1                    January 1997


14.9.1 What is Cachable

   By default, a response is cachable if the requirements of the request
   method, request header fields, and the response status indicate that
   it is cachable. Section 13.4 summarizes these defaults for
   cachability. The following Cache-Control response directives allow an
   origin server to override the default cachability of a response:

public
  Indicates that the response is cachable by any cache, even if it
  would normally be non-cachable or cachable only within a non-shared
  cache. (See also Authorization, section 14.8, for additional
  details.)

private
  Indicates that all or part of the response message is intended for a
  single user and MUST NOT be cached by a shared cache. This allows an
  origin server to state that the specified parts of the response are
  intended for only one user and are not a valid response for requests
  by other users. A private (non-shared) cache may cache the response.

  Note: This usage of the word private only controls where the
  response may be cached, and cannot ensure the privacy of the
  message content.

no-cache
  Indicates that all or part of the response message MUST NOT be cached
  anywhere. This allows an origin server to prevent caching even by
  caches that have been configured to return stale responses to client
  requests.

  Note: Most HTTP/1.0 caches will not recognize or obey this
  directive.

14.9.2 What May be Stored by Caches

   The purpose of the no-store directive is to prevent the inadvertent
   release or retention of sensitive information (for example, on backup
   tapes). The no-store directive applies to the entire message, and may
   be sent either in a response or in a request. If sent in a request, a
   cache MUST NOT store any part of either this request or any response
   to it. If sent in a response, a cache MUST NOT store any part of
   either this response or the request that elicited it. This directive
   applies to both non-shared and shared caches. "MUST NOT store" in
   this context means that the cache MUST NOT intentionally store the
   information in non-volatile storage, and MUST make a best-effort
   attempt to remove the information from volatile storage as promptly
   as possible after forwarding it.



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


   Even when this directive is associated with a response, users may
   explicitly store such a response outside of the caching system (e.g.,
   with a "Save As" dialog). History buffers may store such responses as
   part of their normal operation.

   The purpose of this directive is to meet the stated requirements of
   certain users and service authors who are concerned about accidental
   releases of information via unanticipated accesses to cache data
   structures. While the use of this directive may improve privacy in
   some cases, we caution that it is NOT in any way a reliable or
   sufficient mechanism for ensuring privacy. In particular, malicious
   or compromised caches may not recognize or obey this directive; and
   communications networks may be vulnerable to eavesdropping.

14.9.3 Modifications of the Basic Expiration Mechanism

   The expiration time of an entity may be specified by the origin
   server using the Expires header (see section 14.21). Alternatively,
   it may be specified using the max-age directive in a response.

   If a response includes both an Expires header and a max-age
   directive, the max-age directive overrides the Expires header, even
   if the Expires header is more restrictive. This rule allows an origin
   server to provide, for a given response, a longer expiration time to
   an HTTP/1.1 (or later) cache than to an HTTP/1.0 cache. This may be
   useful if certain HTTP/1.0 caches improperly calculate ages or
   expiration times, perhaps due to desynchronized clocks.

     Note: most older caches, not compliant with this specification, do
     not implement any Cache-Control directives.  An origin server
     wishing to use a Cache-Control directive that restricts, but does
     not prevent, caching by an HTTP/1.1-compliant cache may exploit the
     requirement that the max-age directive overrides the Expires
     header, and the fact that non-HTTP/1.1-compliant caches do not
     observe the max-age directive.

   Other directives allow an user agent to modify the basic expiration
   mechanism. These directives may be specified on a request:

   max-age
     Indicates that the client is willing to accept a response whose age
     is no greater than the specified time in seconds. Unless max-stale
     directive is also included, the client is not willing to accept a
     stale response.

   min-fresh
     Indicates that the client is willing to accept a response whose
     freshness lifetime is no less than its current age plus the



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


     specified time in seconds. That is, the client wants a response
     that will still be fresh for at least the specified number of
     seconds.

   max-stale
     Indicates that the client is willing to accept a response that has
     exceeded its expiration time. If max-stale is assigned a value,
     then the client is willing to accept a response that has exceeded
     its expiration time by no more than the specified number of
     seconds. If no value is assigned to max-stale, then the client is
     willing to accept a stale response of any age.

   If a cache returns a stale response, either because of a max-stale
   directive on a request, or because the cache is configured to
   override the expiration time of a response, the cache MUST attach a
   Warning header to the stale response, using Warning 10 (Response is
   stale).