Ignore:
Timestamp:
Jan 7, 2013, 2:33:47 AM (7 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:
1 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>
Note: See TracChangeset for help on using the changeset viewer.