14.24 If-Modified-Since

   The If-Modified-Since request-header field is used with the GET
   method to make it conditional: if the requested variant has not been
   modified since the time specified in this field, an entity will not



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


   be returned from the server; instead, a 304 (not modified) response
   will be returned without any message-body.

          If-Modified-Since = "If-Modified-Since" ":" HTTP-date

   An example of the field is:

          If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

   A GET method with an If-Modified-Since header and no Range header
   requests that the identified entity be transferred only if it has
   been modified since the date given by the If-Modified-Since header.
   The algorithm for determining this includes the following cases:

   a)If the request would normally result in anything other than a 200
     (OK) status, or if the passed If-Modified-Since date is invalid, the
     response is exactly the same as for a normal GET. A date which is
     later than the server's current time is invalid.

   b)If the variant has been modified since the If-Modified-Since date,
     the response is exactly the same as for a normal GET.

   c)If the variant has not been modified since a valid If-Modified-Since
     date, the server MUST return a 304 (Not Modified) response.

   The purpose of this feature is to allow efficient updates of cached
   information with a minimum amount of transaction overhead.

     Note that the Range request-header field modifies the meaning of
     If-Modified-Since; see section 14.36 for full details.

     Note that If-Modified-Since times are interpreted by the server,
     whose clock may not be synchronized with the client.

   Note that if a client uses an arbitrary date in the If-Modified-Since
   header instead of a date taken from the Last-Modified header for the
   same request, the client should be aware of the fact that this date
   is interpreted in the server's understanding of time. The client
   should consider unsynchronized clocks and rounding problems due to
   the different encodings of time between the client and server. This
   includes the possibility of race conditions if the document has
   changed between the time it was first requested and the If-Modified-
   Since date of a subsequent request, and the possibility of clock-
   skew-related problems if the If-Modified-Since date is derived from
   the client's clock without correction to the server's clock.
   Corrections for different time bases between client and server are at
   best approximate due to network latency.




Fielding, et. al.           Standards Track                   [Page 120]