Changeset 2099 for draft-ietf-httpbis/latest/p4-conditional.html
- Timestamp:
- 07/01/13 10:33:47 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p4-conditional.html
r2093 r2099 449 449 } 450 450 @bottom-center { 451 content: "Expires July 1 0, 2013";451 content: "Expires July 11, 2013"; 452 452 } 453 453 @bottom-right { … … 491 491 <meta name="dct.creator" content="Reschke, J. F."> 492 492 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest"> 493 <meta name="dct.issued" scheme="ISO8601" content="2013-01-0 6">493 <meta name="dct.issued" scheme="ISO8601" content="2013-01-07"> 494 494 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 495 495 <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> 518 518 <tr> 519 <td class="left">Expires: July 1 0, 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> 521 521 </tr> 522 522 </tbody> … … 545 545 in progress”. 546 546 </p> 547 <p>This Internet-Draft will expire on July 1 0, 2013.</p>547 <p>This Internet-Draft will expire on July 11, 2013.</p> 548 548 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 549 549 <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 1020 1020 </li> 1021 1021 </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> 1040 1042 <div id="rfc.iref.i.4"></div> 1041 1043 <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a> <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. 1062 1064 </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, 1067 1068 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 1068 1069 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). 1069 1070 </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 conditional1071 <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 1071 1072 GET to a shared proxy, then the proxy <em class="bcp14">SHOULD</em> forward the 304 response to that client. 1072 1073 </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> 1073 1075 <div id="rfc.iref.21"></div> 1074 1076 <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a> <a id="status.412" href="#status.412">412 Precondition Failed</a></h2>
Note: See TracChangeset
for help on using the changeset viewer.