Changeset 2099 for draft-ietf-httpbis/latest/p4-conditional.html

Timestamp:

07/01/13 10:33:47 (9 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

File:

• draft-ietf-httpbis/latest/p4-conditional.html (modified) (6 diffs)

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

@@ -449 +449 @@
   } 
   @bottom-center {
-       content: "Expires July 10, 2013"; 
+       content: "Expires July 11, 2013"; 
   } 
   @bottom-right {
@@ -491 +491 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2013-01-06">
+      <meta name="dct.issued" scheme="ISO8601" content="2013-01-07">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
       <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.">
@@ -517 +517 @@
             </tr>
             <tr>
-               <td class="left">Expires: July 10, 2013</td>
-               <td class="right">January 6, 2013</td>
+               <td class="left">Expires: July 11, 2013</td>
+               <td class="right">January 7, 2013</td>
             </tr>
          </tbody>
@@ -545 +545 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on July 10, 2013.</p>
+      <p>This Internet-Draft will expire on July 11, 2013.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -1020 +1020 @@
          </li>
       </ol>
-      <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>
-      <ul class="empty">
-         <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.
-         </li>
-         <li> <b>Note:</b> If-Modified-Since times are interpreted by the server, whose clock might not be synchronized with the client.
-         </li>
-         <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
-            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
-            use the exact date string received in a previous <a href="#header.last-modified" class="smpl">Last-Modified</a> header field whenever possible.
-         </li>
-         <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
-            of time. Unsynchronized clocks and rounding problems, due to the different encodings of time between the client and server,
-            are concerns. 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.
-         </li>
-      </ul>
+      <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
+         overhead, and to limit the scope of a web traversal to resources that have recently changed.
+      </p>
+      <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
+         synchronized or when the server has chosen to only honor exact timestamp matches (due to a problem with Last-Modified dates
+         that appear to go "back in time" when the origin server's clock is corrected or a representation is restored from an archived
+         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
+         does not contain a <a href="#header.last-modified" class="smpl">Last-Modified</a> field.
+      </p>
+      <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
+         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
+         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.
+      </p>
+      <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>.
+      </p>
+      <div class="note" id="rfc.section.3.3.p.10"> 
+         <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
+            understanding of time.
+         </p> 
+      </div>
       <div id="rfc.iref.i.4"></div>
       <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>
@@ -1061 +1063 @@
          representation as if it were the payload of a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response.
       </p>
-      <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>
-      <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.
-      </p>
-      <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,
+      <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>.
+      </p>
+      <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,
          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
          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).
       </p>
-      <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
+      <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
          GET to a shared proxy, then the proxy <em class="bcp14">SHOULD</em> forward the 304 response to that client.
       </p>
+      <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>
       <div id="rfc.iref.21"></div>
       <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>