Jan 7, 2013, 2:33:47 AM (7 years ago)

(editorial) Explain the other purpose of If-Modified-Since and why its value might not be from a Last-Modified date; addresses #406

1 edited


  • draft-ietf-httpbis/latest/p4-conditional.xml

    r2093 r2099  
    846    The purpose of this feature is to allow efficient updates of cached
    847    information with a minimum amount of transaction overhead.
    848   <list><t>
    849       &Note; The <x:ref>Range</x:ref> header field modifies the meaning of
    850       If-Modified-Since; see &header-range; for full details.
    851     </t><t>
    852       &Note; If-Modified-Since times are interpreted by the server, whose
    853       clock might not be synchronized with the client.
    854     </t><t>
    855       &Note; When handling an If-Modified-Since header field, some
    856       servers will use an exact date comparison function, rather than a
    857       less-than function, for deciding whether to send a <x:ref>304 (Not Modified)</x:ref>
    858       response. To get best results when sending an If-Modified-Since
    859       header field for cache validation, clients are
    860       advised to use the exact date string received in a previous
    861       <x:ref>Last-Modified</x:ref> header field whenever possible.
    862     </t><t>
    863       &Note; If a client uses an arbitrary date in the If-Modified-Since
    864       header field instead of a date taken from the <x:ref>Last-Modified</x:ref>
    865       header field for the same request, the client needs to be aware that this
    866       date is interpreted in the server's understanding of time.
    867       Unsynchronized clocks and rounding problems, due to the different
    868       encodings of time between the client and server, are concerns.
    869       This includes the possibility of race conditions if the
    870       document has changed between the time it was first requested and
    871       the If-Modified-Since date of a subsequent request, and the
    872       possibility of clock-skew-related problems if the If-Modified-Since
    873       date is derived from the client's clock without correction
    874       to the server's clock. Corrections for different time bases
    875       between client and server are at best approximate due to network
    876       latency.
    877     </t>
    878   </list>
    879 </t>
     846   The two purposes of this feature are to allow efficient updates of cached
     847   information, with a minimum amount of transaction overhead, and to limit
     848   the scope of a web traversal to resources that have recently changed.
     851   When used for cache updates, a cache will typically use the value of the
     852   cached message's <x:ref>Last-Modified</x:ref> field to generate the field
     853   value of If-Modified-Since. This behavior is most interoperable for cases
     854   where clocks are poorly synchronized or when the server has chosen to only
     855   honor exact timestamp matches (due to a problem with Last-Modified dates
     856   that appear to go "back in time" when the origin server's clock is
     857   corrected or a representation is restored from an archived backup).
     858   However, caches occasionally generate the field value based on other data,
     859   such as the <x:ref>Date</x:ref> header field of the cached message or the
     860   local clock time that the message was received, particularly when the
     861   cached message does not contain a <x:ref>Last-Modified</x:ref> field.
     864   When used for limiting the scope of retrieval to a recent time window, a
     865   user agent will generate an If-Modified-Since field value based on either
     866   its own local clock or a <x:ref>Date</x:ref> header field received from the
     867   server during a past run. Origin servers that choose an exact timestamp
     868   match based on the selected representation's <x:ref>Last-Modified</x:ref>
     869   field will not be able to help the user agent limit its data transfers to
     870   only those changed during the specified window.
     873   The <x:ref>Range</x:ref> header field modifies the interpretation of
     874   If-Modified-Since, as defined in &header-range;.
     877  <t>
     878     &Note; If a client uses an arbitrary date in the If-Modified-Since
     879     header field instead of a date taken from a <x:ref>Last-Modified</x:ref>
     880     or <x:ref>Date</x:ref> header field from the origin server, the client
     881     ought to be aware that its date will be interpreted according to the
     882     server's understanding of time.
     883  </t>
    943    A 304 response cannot contain a message-body; it is always
    944    terminated by the first empty line after the header fields.
    945 </t>
    946 <t>
    947    If a <x:ref>200 (OK)</x:ref> response to the same request would have
    948    included any of the header fields
     948   The server generating a 304 response &MUST; generate any of the following
     949   header fields that would have been sent in a <x:ref>200 (OK)</x:ref>
     950   response to the same request:
    949951   <x:ref>Cache-Control</x:ref>,
    950952   <x:ref>Content-Location</x:ref>,
    951953   <x:ref>ETag</x:ref>,
    952    <x:ref>Expires</x:ref>, or
    953    <x:ref>Vary</x:ref>, then
    954    the sender &MUST; generate those same header fields in a 304 response.
     954   <x:ref>Expires</x:ref>, and
     955   <x:ref>Vary</x:ref>.
    968969   conditional GET to a shared proxy, then the proxy &SHOULD; forward the
    969970   304 response to that client.
     973   A 304 response cannot contain a message-body; it is always
     974   terminated by the first empty line after the header fields.
Note: See TracChangeset for help on using the changeset viewer.