Ignore:
Timestamp:
25/01/13 11:25:21 (9 years ago)
Author:
fielding@…
Message:

Refer to conditional requests as being applicable to most methods,
with details added to p4 for when conditionals are not applicable.
Addresses #96

File:
1 edited

Legend:

Unmodified
Added
Removed

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

    r2159 r2161  
    449449  }
    450450  @bottom-center {
    451        content: "Expires July 28, 2013";
     451       content: "Expires July 29, 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-24">
     493      <meta name="dct.issued" scheme="ISO8601" content="2013-01-25">
    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 28, 2013</td>
    520                <td class="right">January 24, 2013</td>
     519               <td class="left">Expires: July 29, 2013</td>
     520               <td class="right">January 25, 2013</td>
    521521            </tr>
    522522         </tbody>
    … …  
    545545         in progress”.
    546546      </p>
    547       <p>This Internet-Draft will expire on July 28, 2013.</p>
     547      <p>This Internet-Draft will expire on July 29, 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>
    … …  
    624624      <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a id="introduction" href="#introduction">Introduction</a></h1>
    625625      <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>.
    629628      </p>
    630629      <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:
    631630         one client accidentally overwriting the work of another client that has been acting in parallel.
    632631      </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 the
     632      <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
    634633         state as observed in a previously obtained representation (one value in that set). A resource might have multiple current
    635634         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&nbsp;5</a>.
    644641      </p>
    645642      <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a id="conformance" href="#conformance">Conformance and Error Handling</a></h2>
    … …  
    868865      </div>
    869866      <h3 id="rfc.section.2.3.3"><a href="#rfc.section.2.3.3">2.3.3</a>&nbsp;<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>):
    871868      </p>
    872869      <div id="rfc.figure.u.5"></div>
    … …  
    10701067      <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
    10711068         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
    10751088         important. In practice, the fields defined in this document are consistently implemented in a single, logical order, due to
    10761089         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.
    10771090      </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 conditions
     1091      <p id="rfc.section.5.p.6">The general rule of conditional precedence is that exact match conditions are evaluated before cache-validating conditions
    10791092         and, within that order, last-modified conditions are only evaluated if the corresponding entity tag condition is not present
    10801093         (or not applicable because the selected representation does not have an entity tag).
    10811094      </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>
    10831096      <ol>
    10841097         <li>When <a href="#header.if-match" class="smpl">If-Match</a> is present, evaluate it:
    … …  
    11181131         </li>
    11191132      </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 regarding
     1133      <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
    11211134         the order for evaluating such fields in relation to those defined in this document and other conditionals that might be found
    11221135         in practice.
    … …  
    12151228      <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a id="security.considerations" href="#security.considerations">Security Considerations</a></h1>
    12161229      <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>.
    12181231      </p>
    12191232      <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
    … …  
    13181331  <a href="#imported.abnf" class="smpl">obs-text</a>      = &lt;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>&gt;
    13191332</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>     = &lt;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>&gt;
     1333      <div id="rfc.figure.u.17"></div><pre class="inline">  <a href="#imported.abnf" class="smpl">HTTP-date</a>     = &lt;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>&gt;
    13211334</pre><h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
    13221335      <div id="rfc.figure.u.18"></div> <pre class="inline"><a href="#header.etag" class="smpl">ETag</a> = entity-tag
    … …  
    14521465                     </ul>
    14531466                  </li>
    1454                   <li><em>Part2</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">2.3.3</a></li>
    1456                         <li><em>Section 5.3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">2.3.3</a></li>
    1457                         <li><em>Section 7.1.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.5">B</a></li>
     1467                  <li><em>Part2</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">1</a></li>
     1469                        <li><em>Section 3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">2.3.3</a></li>
     1470                        <li><em>Section 5.3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">2.3.3</a></li>
     1471                        <li><em>Section 7.1.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.6">B</a></li>
    14581472                     </ul>
    14591473                  </li>
    … …  
    14741488                     </ul>
    14751489                  </li>
    1476                   <li><em>RFC4918</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4918.1">2</a>, <a href="#RFC4918"><b>9.2</b></a></li>
     1490                  <li><em>RFC4918</em>&nbsp;&nbsp;<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>
    14771491                  <li><em>RFC5234</em>&nbsp;&nbsp;<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>
    14781492                        <li><em>Appendix B.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5234.2">B</a></li>
Note: See TracChangeset for help on using the changeset viewer.