Changeset 2161 for draft-ietf-httpbis/latest/p4-conditional.html
- Timestamp:
- 25/01/13 11:25:21 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p4-conditional.html
r2159 r2161 449 449 } 450 450 @bottom-center { 451 content: "Expires July 2 8, 2013";451 content: "Expires July 29, 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-2 4">493 <meta name="dct.issued" scheme="ISO8601" content="2013-01-25"> 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 2 8, 2013</td>520 <td class="right">January 2 4, 2013</td>519 <td class="left">Expires: July 29, 2013</td> 520 <td class="right">January 25, 2013</td> 521 521 </tr> 522 522 </tbody> … … 545 545 in progress”. 546 546 </p> 547 <p>This Internet-Draft will expire on July 2 8, 2013.</p>547 <p>This Internet-Draft will expire on July 29, 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> … … 624 624 <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> <a id="introduction" href="#introduction">Introduction</a></h1> 625 625 <p id="rfc.section.1.p.1">Conditional requests are HTTP requests <a href="#Part2" id="rfc.xref.Part2.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a> that include one or more header fields indicating a precondition to be tested before applying the method semantics to the 626 target resource. Each precondition is based on metadata that is expected to change if the selected representation of the target 627 resource is changed. This document defines the HTTP/1.1 conditional request mechanisms in terms of the architecture, syntax 628 notation, and conformance criteria defined in <a href="#Part1" id="rfc.xref.Part1.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. 626 target resource. This document defines the HTTP/1.1 conditional request mechanisms in terms of the architecture, syntax notation, 627 and conformance criteria defined in <a href="#Part1" id="rfc.xref.Part1.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. 629 628 </p> 630 629 <p id="rfc.section.1.p.2">Conditional GET requests are the most efficient mechanism for HTTP cache updates <a href="#Part6" id="rfc.xref.Part6.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>. Conditionals can also be applied to state-changing methods, such as PUT and DELETE, to prevent the "lost update" problem: 631 630 one client accidentally overwriting the work of another client that has been acting in parallel. 632 631 </p> 633 <p id="rfc.section.1.p.3"> Conditional request preconditions are based on the state of the target resource as a whole (its current value set) or the632 <p id="rfc.section.1.p.3"><span id="rfc.iref.s.1"></span> Conditional request preconditions are based on the state of the target resource as a whole (its current value set) or the 634 633 state as observed in a previously obtained representation (one value in that set). A resource might have multiple current 635 634 representations, each with its own observable state. The conditional request mechanisms assume that the mapping of requests 636 to corresponding representations will be consistent over time if the server intends to take advantage of conditionals. Regardless, 637 if the mapping is inconsistent and the server is unable to select the appropriate representation, then no harm will result 638 when the precondition evaluates to false. 639 </p> 640 <p id="rfc.section.1.p.4"><span id="rfc.iref.s.1"></span> We use the term "<dfn>selected representation</dfn>" to refer to the current representation of the target resource that would have been selected in a successful response if 641 the same request had used the method GET and had excluded all of the conditional request header fields. The conditional request 642 preconditions are evaluated by comparing the values provided in the request header fields to the current metadata for the 643 selected representation. 635 to a "selected representation" (<a href="p2-semantics.html#representations" title="Representations">Section 3</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) will be consistent over time if the server intends to take advantage of conditionals. Regardless, if the mapping is inconsistent 636 and the server is unable to select the appropriate representation, then no harm will result when the precondition evaluates 637 to false. 638 </p> 639 <p id="rfc.section.1.p.4">The conditional request preconditions defined by this specification are evaluated by comparing the validators provided in 640 the conditional request header fields to the current validators for the selected representation in the order defined by <a href="#precedence" title="Evaluation and Precedence">Section 5</a>. 644 641 </p> 645 642 <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a> <a id="conformance" href="#conformance">Conformance and Error Handling</a></h2> … … 868 865 </div> 869 866 <h3 id="rfc.section.2.3.3"><a href="#rfc.section.2.3.3">2.3.3</a> <a id="example.entity.tag.vs.conneg" href="#example.entity.tag.vs.conneg">Example: Entity-tags Varying on Content-Negotiated Resources</a></h3> 870 <p id="rfc.section.2.3.3.p.1">Consider a resource that is subject to content negotiation (<a href="p2-semantics.html#content.negotiation" title="Content Negotiation">Section 3.4</a> of <a href="#Part2" id="rfc.xref.Part2. 2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), and where the representations sent in response to a GET request vary based on the <a href="p2-semantics.html#header.accept-encoding" class="smpl">Accept-Encoding</a> request header field (<a href="p2-semantics.html#header.accept-encoding" title="Accept-Encoding">Section 5.3.4</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>):867 <p id="rfc.section.2.3.3.p.1">Consider a resource that is subject to content negotiation (<a href="p2-semantics.html#content.negotiation" title="Content Negotiation">Section 3.4</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), and where the representations sent in response to a GET request vary based on the <a href="p2-semantics.html#header.accept-encoding" class="smpl">Accept-Encoding</a> request header field (<a href="p2-semantics.html#header.accept-encoding" title="Accept-Encoding">Section 5.3.4</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>): 871 868 </p> 872 869 <div id="rfc.figure.u.5"></div> … … 1070 1067 <p id="rfc.section.5.p.1">For each conditional request, a server <em class="bcp14">MUST</em> evaluate the request preconditions after it has successfully performed its normal request checks (i.e., just before it would 1071 1068 perform the action associated with the request method). Preconditions are ignored if the server determines that an error or 1072 redirect response applies before they are evaluated. 1073 </p> 1074 <p id="rfc.section.5.p.2">When more than one conditional request header field is present in a request, the order in which the fields are evaluated becomes 1069 redirect response applies before they are evaluated. Otherwise, the evaluation depends on both the method semantics and the 1070 choice of conditional. 1071 </p> 1072 <p id="rfc.section.5.p.2">A conditional request header field that is designed specifically for cache validation, which includes <a href="#header.if-none-match" class="smpl">If-None-Match</a> and <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a> when used in a GET or HEAD request, allows cached representations to be refreshed without repeatedly transferring data already 1073 held by the client. Evaluating to false is thus an indication that the client can continue to use its local copy of the selected 1074 representation, as indicated by the server generating a <a href="#status.304" class="smpl">304 (Not Modified)</a> response that includes only those header fields useful for refreshing the cached representation. 1075 </p> 1076 <p id="rfc.section.5.p.3">All other conditionals are intended to signal failure when the precondition evaluates to false. For example, an <a href="#header.if-match" class="smpl">If-Match</a> conditional sent with a state-changing method (e.g., POST, PUT, DELETE) is intended to prevent the request from taking effect 1077 on the target resource if the resource state does not match the expected state. In other words, evaluating the condition to 1078 false means that the resource has been changed by some other client, perhaps by another user attempting to edit the same resource, 1079 and thus preventing the request from being applied saves the client from overwriting some other client's work. This result 1080 is indicated by the server generating a <a href="#status.412" class="smpl">412 (Precondition Failed)</a> response. 1081 </p> 1082 <p id="rfc.section.5.p.4">The conditional request header fields defined by this specification are ignored for request methods that never involve the 1083 selection or modification of a <a href="p2-semantics.html#representations" class="smpl">selected representation</a> (e.g., CONNECT, OPTIONS, and TRACE). Other conditional request header fields, defined by extensions to HTTP, might place conditions 1084 on the state of the target resource in general, such as how the If header field in WebDAV has been defined to make a request 1085 conditional on the presence or absence of a lock <a href="#RFC4918" id="rfc.xref.RFC4918.2"><cite title="HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)">[RFC4918]</cite></a>. 1086 </p> 1087 <p id="rfc.section.5.p.5">When more than one conditional request header field is present in a request, the order in which the fields are evaluated becomes 1075 1088 important. In practice, the fields defined in this document are consistently implemented in a single, logical order, due to 1076 1089 the fact that entity tags are presumed to be more accurate than date validators. For example, the only reason to send both <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a> and <a href="#header.if-none-match" class="smpl">If-None-Match</a> in the same GET request is to support intermediary caches that might not have implemented <a href="#header.if-none-match" class="smpl">If-None-Match</a>, so it makes sense to ignore the <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a> when entity tags are understood and available for the selected representation. 1077 1090 </p> 1078 <p id="rfc.section.5.p. 3">The general rule of conditional precedence is that exact match conditions are evaluated before cache-validating conditions1091 <p id="rfc.section.5.p.6">The general rule of conditional precedence is that exact match conditions are evaluated before cache-validating conditions 1079 1092 and, within that order, last-modified conditions are only evaluated if the corresponding entity tag condition is not present 1080 1093 (or not applicable because the selected representation does not have an entity tag). 1081 1094 </p> 1082 <p id="rfc.section.5.p. 4">Specifically, the fields defined by this specification are evaluated as follows: </p>1095 <p id="rfc.section.5.p.7">Specifically, the fields defined by this specification are evaluated as follows: </p> 1083 1096 <ol> 1084 1097 <li>When <a href="#header.if-match" class="smpl">If-Match</a> is present, evaluate it: … … 1118 1131 </li> 1119 1132 </ol> 1120 <p id="rfc.section.5.p. 5">Any extension to HTTP/1.1 that defines additional conditional request header fields ought to define its own expectations regarding1133 <p id="rfc.section.5.p.8">Any extension to HTTP/1.1 that defines additional conditional request header fields ought to define its own expectations regarding 1121 1134 the order for evaluating such fields in relation to those defined in this document and other conditionals that might be found 1122 1135 in practice. … … 1215 1228 <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="security.considerations" href="#security.considerations">Security Considerations</a></h1> 1216 1229 <p id="rfc.section.7.p.1">This section is meant to inform developers, information providers, and users of known security concerns specific to the HTTP/1.1 1217 conditional request mechanisms. More general security considerations are addressed in HTTP messaging <a href="#Part1" id="rfc.xref.Part1.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a> and semantics <a href="#Part2" id="rfc.xref.Part2. 4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>.1230 conditional request mechanisms. More general security considerations are addressed in HTTP messaging <a href="#Part1" id="rfc.xref.Part1.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a> and semantics <a href="#Part2" id="rfc.xref.Part2.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>. 1218 1231 </p> 1219 1232 <p id="rfc.section.7.p.2">The validators defined by this specification are not intended to ensure the validity of a representation, guard against malicious … … 1318 1331 <a href="#imported.abnf" class="smpl">obs-text</a> = <obs-text, defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>> 1319 1332 </pre><p id="rfc.section.B.p.4">The rules below are defined in other parts:</p> 1320 <div id="rfc.figure.u.17"></div><pre class="inline"> <a href="#imported.abnf" class="smpl">HTTP-date</a> = <HTTP-date, defined in <a href="#Part2" id="rfc.xref.Part2. 5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 7.1.1.1</a>>1333 <div id="rfc.figure.u.17"></div><pre class="inline"> <a href="#imported.abnf" class="smpl">HTTP-date</a> = <HTTP-date, defined in <a href="#Part2" id="rfc.xref.Part2.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 7.1.1.1</a>> 1321 1334 </pre><h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> 1322 1335 <div id="rfc.figure.u.18"></div> <pre class="inline"><a href="#header.etag" class="smpl">ETag</a> = entity-tag … … 1452 1465 </ul> 1453 1466 </li> 1454 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.3.3</a>, <a href="#rfc.xref.Part2.3">2.3.3</a>, <a href="#rfc.xref.Part2.4">7</a>, <a href="#Part2"><b>9.1</b></a>, <a href="#rfc.xref.Part2.5">B</a><ul> 1455 <li><em>Section 3.4</em> <a href="#rfc.xref.Part2.2">2.3.3</a></li> 1456 <li><em>Section 5.3.4</em> <a href="#rfc.xref.Part2.3">2.3.3</a></li> 1457 <li><em>Section 7.1.1.1</em> <a href="#rfc.xref.Part2.5">B</a></li> 1467 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">1</a>, <a href="#rfc.xref.Part2.3">2.3.3</a>, <a href="#rfc.xref.Part2.4">2.3.3</a>, <a href="#rfc.xref.Part2.5">7</a>, <a href="#Part2"><b>9.1</b></a>, <a href="#rfc.xref.Part2.6">B</a><ul> 1468 <li><em>Section 3</em> <a href="#rfc.xref.Part2.2">1</a></li> 1469 <li><em>Section 3.4</em> <a href="#rfc.xref.Part2.3">2.3.3</a></li> 1470 <li><em>Section 5.3.4</em> <a href="#rfc.xref.Part2.4">2.3.3</a></li> 1471 <li><em>Section 7.1.1.1</em> <a href="#rfc.xref.Part2.6">B</a></li> 1458 1472 </ul> 1459 1473 </li> … … 1474 1488 </ul> 1475 1489 </li> 1476 <li><em>RFC4918</em> <a href="#rfc.xref.RFC4918.1">2</a>, <a href="# RFC4918"><b>9.2</b></a></li>1490 <li><em>RFC4918</em> <a href="#rfc.xref.RFC4918.1">2</a>, <a href="#rfc.xref.RFC4918.2">5</a>, <a href="#RFC4918"><b>9.2</b></a></li> 1477 1491 <li><em>RFC5234</em> <a href="#rfc.xref.RFC5234.1">1.2</a>, <a href="#RFC5234"><b>9.1</b></a>, <a href="#rfc.xref.RFC5234.2">B</a><ul> 1478 1492 <li><em>Appendix B.1</em> <a href="#rfc.xref.RFC5234.2">B</a></li>
Note: See TracChangeset
for help on using the changeset viewer.