Ignore:
Timestamp:
07/01/13 10:33:47 (10 years ago)
Author:
fielding@…
Message:

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

Location:
draft-ietf-httpbis/latest
Files:
2 edited

Legend:

Unmodified
Added
Removed

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

    r2093 r2099  
    449449  }
    450450  @bottom-center {
    451        content: "Expires July 10, 2013";
     451       content: "Expires July 11, 2013";
    452452  }
    453453  @bottom-right {
    … …  
    491491      <meta name="dct.creator" content="Reschke, J. F.">
    492492      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest">
    493       <meta name="dct.issued" scheme="ISO8601" content="2013-01-06">
     493      <meta name="dct.issued" scheme="ISO8601" content="2013-01-07">
    494494      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    495495      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false.">
    … …  
    517517            </tr>
    518518            <tr>
    519                <td class="left">Expires: July 10, 2013</td>
    520                <td class="right">January 6, 2013</td>
     519               <td class="left">Expires: July 11, 2013</td>
     520               <td class="right">January 7, 2013</td>
    521521            </tr>
    522522         </tbody>
    … …  
    545545         in progress”.
    546546      </p>
    547       <p>This Internet-Draft will expire on July 10, 2013.</p>
     547      <p>This Internet-Draft will expire on July 11, 2013.</p>
    548548      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    549549      <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    10201020         </li>
    10211021      </ol>
    1022       <p id="rfc.section.3.3.p.6">The purpose of this feature is to allow efficient updates of cached information with a minimum amount of transaction overhead. </p>
    1023       <ul class="empty">
    1024          <li> <b>Note:</b> The <a href="p5-range.html#range.retrieval.requests" class="smpl">Range</a> header field modifies the meaning of If-Modified-Since; see <a href="p5-range.html#header.range" title="Range">Section 5.4</a> of <a href="#Part5" id="rfc.xref.Part5.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a> for full details.
    1025          </li>
    1026          <li> <b>Note:</b> If-Modified-Since times are interpreted by the server, whose clock might not be synchronized with the client.
    1027          </li>
    1028          <li> <b>Note:</b> When handling an If-Modified-Since header field, some servers will use an exact date comparison function, rather than a less-than
    1029             function, for deciding whether to send a <a href="#status.304" class="smpl">304 (Not Modified)</a> response. To get best results when sending an If-Modified-Since header field for cache validation, clients are advised to
    1030             use the exact date string received in a previous <a href="#header.last-modified" class="smpl">Last-Modified</a> header field whenever possible.
    1031          </li>
    1032          <li> <b>Note:</b> If a client uses an arbitrary date in the If-Modified-Since header field instead of a date taken from the <a href="#header.last-modified" class="smpl">Last-Modified</a> header field for the same request, the client needs to be aware that this date is interpreted in the server's understanding
    1033             of time. Unsynchronized clocks and rounding problems, due to the different encodings of time between the client and server,
    1034             are concerns. This includes the possibility of race conditions if the document has changed between the time it was first requested
    1035             and the If-Modified-Since date of a subsequent request, and the possibility of clock-skew-related problems if the If-Modified-Since
    1036             date is derived from the client's clock without correction to the server's clock. Corrections for different time bases between
    1037             client and server are at best approximate due to network latency.
    1038          </li>
    1039       </ul>
     1022      <p id="rfc.section.3.3.p.6">The two purposes of this feature are to allow efficient updates of cached information, with a minimum amount of transaction
     1023         overhead, and to limit the scope of a web traversal to resources that have recently changed.
     1024      </p>
     1025      <p id="rfc.section.3.3.p.7">When used for cache updates, a cache will typically use the value of the cached message's <a href="#header.last-modified" class="smpl">Last-Modified</a> field to generate the field value of If-Modified-Since. This behavior is most interoperable for cases where clocks are poorly
     1026         synchronized or when the server has chosen to only honor exact timestamp matches (due to a problem with Last-Modified dates
     1027         that appear to go "back in time" when the origin server's clock is corrected or a representation is restored from an archived
     1028         backup). However, caches occasionally generate the field value based on other data, such as the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field of the cached message or the local clock time that the message was received, particularly when the cached message
     1029         does not contain a <a href="#header.last-modified" class="smpl">Last-Modified</a> field.
     1030      </p>
     1031      <p id="rfc.section.3.3.p.8">When used for limiting the scope of retrieval to a recent time window, a user agent will generate an If-Modified-Since field
     1032         value based on either its own local clock or a <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field received from the server during a past run. Origin servers that choose an exact timestamp match based on the
     1033         selected representation's <a href="#header.last-modified" class="smpl">Last-Modified</a> field will not be able to help the user agent limit its data transfers to only those changed during the specified window.
     1034      </p>
     1035      <p id="rfc.section.3.3.p.9">The <a href="p5-range.html#range.retrieval.requests" class="smpl">Range</a> header field modifies the interpretation of If-Modified-Since, as defined in <a href="p5-range.html#header.range" title="Range">Section 5.4</a> of <a href="#Part5" id="rfc.xref.Part5.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>.
     1036      </p>
     1037      <div class="note" id="rfc.section.3.3.p.10">
     1038         <p> <b>Note:</b> If a client uses an arbitrary date in the If-Modified-Since header field instead of a date taken from a <a href="#header.last-modified" class="smpl">Last-Modified</a> or <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field from the origin server, the client ought to be aware that its date will be interpreted according to the server's
     1039            understanding of time.
     1040         </p>
     1041      </div>
    10401042      <div id="rfc.iref.i.4"></div>
    10411043      <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a>&nbsp;<a id="header.if-unmodified-since" href="#header.if-unmodified-since">If-Unmodified-Since</a></h2>
    … …  
    10611063         representation as if it were the payload of a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response.
    10621064      </p>
    1063       <p id="rfc.section.4.1.p.2">A 304 response cannot contain a message-body; it is always terminated by the first empty line after the header fields.</p>
    1064       <p id="rfc.section.4.1.p.3">If a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to the same request would have included any of the header fields <a href="p6-cache.html#header.cache-control" class="smpl">Cache-Control</a>, <a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a>, <a href="#header.etag" class="smpl">ETag</a>, <a href="p6-cache.html#header.expires" class="smpl">Expires</a>, or <a href="p2-semantics.html#header.vary" class="smpl">Vary</a>, then the sender <em class="bcp14">MUST</em> generate those same header fields in a 304 response.
    1065       </p>
    1066       <p id="rfc.section.4.1.p.4">Since the goal of a 304 response is to minimize information transfer when the recipient already has one or more cached representations,
     1065      <p id="rfc.section.4.1.p.2">The server generating a 304 response <em class="bcp14">MUST</em> generate any of the following header fields that would have been sent in a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to the same request: <a href="p6-cache.html#header.cache-control" class="smpl">Cache-Control</a>, <a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a>, <a href="#header.etag" class="smpl">ETag</a>, <a href="p6-cache.html#header.expires" class="smpl">Expires</a>, and <a href="p2-semantics.html#header.vary" class="smpl">Vary</a>.
     1066      </p>
     1067      <p id="rfc.section.4.1.p.3">Since the goal of a 304 response is to minimize information transfer when the recipient already has one or more cached representations,
    10671068         a sender <em class="bcp14">SHOULD NOT</em> generate representation metadata other than the above listed fields unless said metadata exists for the purpose of guiding
    10681069         cache updates (e.g., <a href="#header.last-modified" class="smpl">Last-Modified</a> might be useful if the response does not have an <a href="#header.etag" class="smpl">ETag</a> field).
    10691070      </p>
    1070       <p id="rfc.section.4.1.p.5">Requirements on a cache that receives a 304 response are defined in <a href="p6-cache.html#freshening.responses" title="Freshening Responses with 304 Not Modified">Section 4.2.1</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>. If the conditional request originated with an outbound client, such as a user agent with its own cache sending a conditional
     1071      <p id="rfc.section.4.1.p.4">Requirements on a cache that receives a 304 response are defined in <a href="p6-cache.html#freshening.responses" title="Freshening Responses with 304 Not Modified">Section 4.2.1</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>. If the conditional request originated with an outbound client, such as a user agent with its own cache sending a conditional
    10711072         GET to a shared proxy, then the proxy <em class="bcp14">SHOULD</em> forward the 304 response to that client.
    10721073      </p>
     1074      <p id="rfc.section.4.1.p.5">A 304 response cannot contain a message-body; it is always terminated by the first empty line after the header fields.</p>
    10731075      <div id="rfc.iref.21"></div>
    10741076      <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a id="status.412" href="#status.412">412 Precondition Failed</a></h2>

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

    r2093 r2099  
    844844</t>
    845845<t>
    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.
     849</t>
     850<t>
     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.
     862</t>
     863<t>
     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.
     871</t>
     872<t>
     873   The <x:ref>Range</x:ref> header field modifies the interpretation of
     874   If-Modified-Since, as defined in &header-range;.
     875</t>
     876<x:note>
     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>
     884</x:note>
    880885</section>
    881886
    … …  
    941946</t>
    942947<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>.
    955956</t>
    956957<t>
    … …  
    968969   conditional GET to a shared proxy, then the proxy &SHOULD; forward the
    969970   304 response to that client.
     971</t>
     972<t>
     973   A 304 response cannot contain a message-body; it is always
     974   terminated by the first empty line after the header fields.
    970975</t>
    971976</section>
Note: See TracChangeset for help on using the changeset viewer.