13.2.4 Expiration Calculations

   In order to decide whether a response is fresh or stale, we need to
   compare its freshness lifetime to its age. The age is calculated as
   described in section 13.2.3; this section describes how to calculate
   the freshness lifetime, and to determine if a response has expired.
   In the discussion below, the values can be represented in any form
   appropriate for arithmetic operations.

   We use the term "expires_value" to denote the value of the Expires
   header. We use the term "max_age_value" to denote an appropriate
   value of the number of seconds carried by the max-age directive of
   the Cache-Control header in a response (see section 14.10.

   The max-age directive takes priority over Expires, so if max-age is
   present in a response, the calculation is simply:

         freshness_lifetime = max_age_value

   Otherwise, if Expires is present in the response, the calculation is:

         freshness_lifetime = expires_value - date_value

   Note that neither of these calculations is vulnerable to clock skew,
   since all of the information comes from the origin server.

   If neither Expires nor Cache-Control: max-age appears in the
   response, and the response does not include other restrictions on
   caching, the cache MAY compute a freshness lifetime using a
   heuristic. If the value is greater than 24 hours, the cache must
   attach Warning 13 to any response whose age is more than 24 hours if



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


   such warning has not already been added.

   Also, if the response does have a Last-Modified time, the heuristic
   expiration value SHOULD be no more than some fraction of the interval
   since that time. A typical setting of this fraction might be 10%.

   The calculation to determine if a response has expired is quite
   simple:

         response_is_fresh = (freshness_lifetime > current_age)

13.2.5 Disambiguating Expiration Values

   Because expiration values are assigned optimistically, it is possible
   for two caches to contain fresh values for the same resource that are
   different.

   If a client performing a retrieval receives a non-first-hand response
   for a request that was already fresh in its own cache, and the Date
   header in its existing cache entry is newer than the Date on the new
   response, then the client MAY ignore the response. If so, it MAY
   retry the request with a "Cache-Control: max-age=0" directive (see
   section 14.9), to force a check with the origin server.

   If a cache has two fresh responses for the same representation with
   different validators, it MUST use the one with the more recent Date
   header. This situation may arise because the cache is pooling
   responses from other caches, or because a client has asked for a
   reload or a revalidation of an apparently fresh cache entry.

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.





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


   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.