13.3 Validation Model

   When a cache has a stale entry that it would like to use as a
   response to a client's request, it first has to check with the origin
   server (or possibly an intermediate cache with a fresh response) to
   see if its cached entry is still usable. We call this "validating"
   the cache entry.  Since we do not want to have to pay the overhead of
   retransmitting the full response if the cached entry is good, and we
   do not want to pay the overhead of an extra round trip if the cached
   entry is invalid, the HTTP/1.1 protocol supports the use of
   conditional methods.

   The key protocol features for supporting conditional methods are
   those concerned with "cache validators." When an origin server
   generates a full response, it attaches some sort of validator to it,
   which is kept with the cache entry. When a client (user agent or
   proxy cache) makes a conditional request for a resource for which it
   has a cache entry, it includes the associated validator in the
   request.

   The server then checks that validator against the current validator
   for the entity, and, if they match, it responds with a special status
   code (usually, 304 (Not Modified)) and no entity-body. Otherwise, it
   returns a full response (including entity-body). Thus, we avoid
   transmitting the full response if the validator matches, and we avoid
   an extra round trip if it does not match.




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


     Note: the comparison functions used to decide if validators match
     are defined in section 13.3.3.

   In HTTP/1.1, a conditional request looks exactly the same as a normal
   request for the same resource, except that it carries a special
   header (which includes the validator) that implicitly turns the
   method (usually, GET) into a conditional.

   The protocol includes both positive and negative senses of cache-
   validating conditions. That is, it is possible to request either that
   a method be performed if and only if a validator matches or if and
   only if no validators match.

     Note: a response that lacks a validator may still be cached, and
     served from cache until it expires, unless this is explicitly
     prohibited by a Cache-Control directive. However, a cache cannot do
     a conditional retrieval if it does not have a validator for the
     entity, which means it will not be refreshable after it expires.

13.3.1 Last-modified Dates

   The Last-Modified entity-header field value is often used as a cache
   validator. In simple terms, a cache entry is considered to be valid
   if the entity has not been modified since the Last-Modified value.

13.3.2 Entity Tag Cache Validators

   The ETag entity-header field value, an entity tag, provides for an
   "opaque" cache validator. This may allow more reliable validation in
   situations where it is inconvenient to store modification dates,
   where the one-second resolution of HTTP date values is not
   sufficient, or where the origin server wishes to avoid certain
   paradoxes that may arise from the use of modification dates.

   Entity Tags are described in section 3.11. The headers used with
   entity tags are described in sections 14.20, 14.25, 14.26 and 14.43.