Ignore:
Timestamp:
19/01/13 13:53:26 (8 years ago)
Author:
fielding@…
Message:

Define time of evaluation along with precedence; remove more duplicate and conflicting requirements revealed by the addition of 428 (Precondition Required); reduce requirements targeting entity-tag to facts; clarify that servers only need to send validators on successful retrieval responses; addresses #350 and #427

File:
1 edited

Legend:

Unmodified
Added
Removed

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

    r2116 r2128  
    449449  }
    450450  @bottom-center {
    451        content: "Expires July 16, 2013";
     451       content: "Expires July 23, 2013";
    452452  }
    453453  @bottom-right {
    … …  
    475475      <link rel="Chapter" title="3 Precondition Header Fields" href="#rfc.section.3">
    476476      <link rel="Chapter" title="4 Status Code Definitions" href="#rfc.section.4">
    477       <link rel="Chapter" title="5 Precedence" href="#rfc.section.5">
     477      <link rel="Chapter" title="5 Evaluation and Precedence" href="#rfc.section.5">
    478478      <link rel="Chapter" title="6 IANA Considerations" href="#rfc.section.6">
    479479      <link rel="Chapter" title="7 Security Considerations" href="#rfc.section.7">
    … …  
    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-12">
     493      <meta name="dct.issued" scheme="ISO8601" content="2013-01-19">
    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 16, 2013</td>
    520                <td class="right">January 12, 2013</td>
     519               <td class="left">Expires: July 23, 2013</td>
     520               <td class="right">January 19, 2013</td>
    521521            </tr>
    522522         </tbody>
    … …  
    545545         in progress”.
    546546      </p>
    547       <p>This Internet-Draft will expire on July 16, 2013.</p>
     547      <p>This Internet-Draft will expire on July 23, 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>
    … …  
    581581                  </ul>
    582582               </li>
    583                <li><a href="#rfc.section.2.4">2.4</a>&nbsp;&nbsp;&nbsp;<a href="#rules.for.when.to.use.entity.tags.and.last-modified.dates">Rules for When to Use Entity-tags and Last-Modified Dates</a></li>
     583               <li><a href="#rfc.section.2.4">2.4</a>&nbsp;&nbsp;&nbsp;<a href="#when.to.use.entity.tags.and.last-modified.dates">When to Use Entity-tags and Last-Modified Dates</a></li>
    584584            </ul>
    585585         </li>
    … …  
    597597            </ul>
    598598         </li>
    599          <li><a href="#rfc.section.5">5.</a>&nbsp;&nbsp;&nbsp;<a href="#precedence">Precedence</a></li>
     599         <li><a href="#rfc.section.5">5.</a>&nbsp;&nbsp;&nbsp;<a href="#precedence">Evaluation and Precedence</a></li>
    600600         <li><a href="#rfc.section.6">6.</a>&nbsp;&nbsp;&nbsp;<a href="#IANA.considerations">IANA Considerations</a><ul>
    601601               <li><a href="#rfc.section.6.1">6.1</a>&nbsp;&nbsp;&nbsp;<a href="#status.code.registration">Status Code Registration</a></li>
    … …  
    666666         in use and imposes restrictions on when weak validators can be used as preconditions.
    667667      </p>
    668       <p id="rfc.section.2.1.p.2">A "strong validator" is a representation metadata value that <em class="bcp14">MUST</em> be changed to a new, previously unused or guaranteed unique, value whenever a change occurs to the representation data such
    669          that a change would be observable in the payload body of a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to GET.
    670       </p>
    671       <p id="rfc.section.2.1.p.3">A strong validator <em class="bcp14">MAY</em> be changed for other reasons, such as when a semantically significant part of the representation metadata is changed (e.g., <a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a>), but it is in the best interests of the origin server to only change the value when it is necessary to invalidate the stored
    672          responses held by remote caches and authoring tools. A strong validator <em class="bcp14">MUST</em> be unique across all representations of a given resource, such that no two representations of that resource share the same
    673          validator unless their payload body would be identical.
     668      <p id="rfc.section.2.1.p.2">A "strong validator" is a representation metadata value that is changed to a new, previously unused or guaranteed unique,
     669         value whenever a change occurs to the representation data such that a change would be observable in the payload body of a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to GET.
     670      </p>
     671      <p id="rfc.section.2.1.p.3">A strong validator might change for other reasons, such as when a semantically significant part of the representation metadata
     672         is changed (e.g., <a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a>), but it is in the best interests of the origin server to only change the value when it is necessary to invalidate the stored
     673         responses held by remote caches and authoring tools. A strong validator is unique across all representations of a given resource,
     674         such that no two representations of that resource share the same validator unless their payload body would be identical.
    674675      </p>
    675676      <p id="rfc.section.2.1.p.4">Cache entries might persist for arbitrarily long periods, regardless of expiration times. Thus, a cache might attempt to validate
    676          an entry using a validator that it obtained in the distant past. A strong validator <em class="bcp14">MUST</em> be unique across all versions of all representations associated with a particular resource over time. However, there is no
    677          implication of uniqueness across representations of different resources (i.e., the same strong validator might be in use for
    678          representations of multiple resources at the same time and does not imply that those representations are equivalent).
     677         an entry using a validator that it obtained in the distant past. A strong validator is unique across all versions of all representations
     678         associated with a particular resource over time. However, there is no implication of uniqueness across representations of
     679         different resources (i.e., the same strong validator might be in use for representations of multiple resources at the same
     680         time and does not imply that those representations are equivalent).
    679681      </p>
    680682      <p id="rfc.section.2.1.p.5">There are a variety of strong validators used in practice. The best are based on strict revision control, wherein each change
    … …  
    791793  ETag: ""
    792794</pre><p id="rfc.section.2.3.p.6">An entity-tag can be either a weak or strong validator, with strong being the default. If an origin server provides an entity-tag
    793          for a representation and the generation of that entity-tag does not satisfy the requirements for a strong validator (<a href="#weak.and.strong.validators" title="Weak versus Strong">Section&nbsp;2.1</a>), then that entity-tag <em class="bcp14">MUST</em> be marked as weak by prefixing its opaque value with "W/" (case-sensitive).
     795         for a representation and the generation of that entity-tag does not satisfy the requirements for a strong validator (<a href="#weak.and.strong.validators" title="Weak versus Strong">Section&nbsp;2.1</a>), then the origin server <em class="bcp14">MUST</em> mark the entity-tag as weak by prefixing its opaque value with "W/" (case-sensitive).
    794796      </p>
    795797      <h3 id="rfc.section.2.3.1"><a href="#rfc.section.2.3.1">2.3.1</a>&nbsp;<a id="entity.tag.generation" href="#entity.tag.generation">Generation</a></h3>
    … …  
    813815      </p>
    814816      <ul>
    815          <li>The strong comparison function: in order to be considered equal, both opaque-tags <em class="bcp14">MUST</em> be identical character-by-character, and both <em class="bcp14">MUST NOT</em> be weak.
    816          </li>
    817          <li>The weak comparison function: in order to be considered equal, both opaque-tags <em class="bcp14">MUST</em> be identical character-by-character, but either or both of them <em class="bcp14">MAY</em> be tagged as "weak" without affecting the result.
     817         <li><dfn>Strong comparison</dfn>: two entity-tags are equivalent if both are not weak and their opaque-tags match character-by-character.
     818         </li>
     819         <li><dfn>Weak comparison</dfn>: two entity-tags are equivalent if their opaque-tags match character-by-character, regardless of either or both being tagged
     820            as "weak".
    818821         </li>
    819822      </ul>
    … …  
    895898         </p>
    896899      </div>
    897       <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a>&nbsp;<a id="rules.for.when.to.use.entity.tags.and.last-modified.dates" href="#rules.for.when.to.use.entity.tags.and.last-modified.dates">Rules for When to Use Entity-tags and Last-Modified Dates</a></h2>
     900      <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a>&nbsp;<a id="when.to.use.entity.tags.and.last-modified.dates" href="#when.to.use.entity.tags.and.last-modified.dates">When to Use Entity-tags and Last-Modified Dates</a></h2>
    898901      <p id="rfc.section.2.4.p.1">We adopt a set of rules and recommendations for origin servers, clients, and caches regarding when various validator types
    899902         ought to be used, and for what purposes.
    900903      </p>
    901       <p id="rfc.section.2.4.p.2">HTTP/1.1 origin servers: </p>
     904      <p id="rfc.section.2.4.p.2">In <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> responses to GET or HEAD, an origin server:
     905      </p>
    902906      <ul>
    903907         <li><em class="bcp14">SHOULD</em> send an entity-tag validator unless it is not feasible to generate one.
    … …  
    909913         </li>
    910914      </ul>
    911       <p id="rfc.section.2.4.p.3">In other words, the preferred behavior for an HTTP/1.1 origin server is to send both a strong entity-tag and a <a href="#header.last-modified" class="smpl">Last-Modified</a> value.
    912       </p>
    913       <p id="rfc.section.2.4.p.4">HTTP/1.1 clients: </p>
     915      <p id="rfc.section.2.4.p.3">In other words, the preferred behavior for an origin server is to send both a strong entity-tag and a <a href="#header.last-modified" class="smpl">Last-Modified</a> value in successful responses to a retrieval request.
     916      </p>
     917      <p id="rfc.section.2.4.p.4">A client: </p>
    914918      <ul>
    915919         <li><em class="bcp14">MUST</em> use that entity-tag in any cache-conditional request (using <a href="#header.if-match" class="smpl">If-Match</a> or <a href="#header.if-none-match" class="smpl">If-None-Match</a>) if an entity-tag has been provided by the origin server.
    … …  
    922926         </li>
    923927      </ul>
    924       <p id="rfc.section.2.4.p.5">An HTTP/1.1 origin server, upon receiving a conditional request that includes both a Last-Modified date (e.g., in an <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a> or <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> header field) and one or more entity-tags (e.g., in an <a href="#header.if-match" class="smpl">If-Match</a>, <a href="#header.if-none-match" class="smpl">If-None-Match</a>, or <a href="p5-range.html#header.if-range" class="smpl">If-Range</a> header field) as cache validators, <em class="bcp14">MUST NOT</em> send a response status code of <a href="#status.304" class="smpl">304 (Not Modified)</a> unless doing so is consistent with all of the conditional header fields in the request.
    925       </p>
    926       <p id="rfc.section.2.4.p.6">An HTTP/1.1 caching proxy, upon receiving a conditional request that includes both a Last-Modified date and one or more entity-tags
    927          as cache validators, <em class="bcp14">MUST NOT</em> send a locally cached response to the client unless that cached response is consistent with all of the conditional header
    928          fields in the request.
    929       </p>
    930       <ul class="empty">
    931          <li> <b>Note:</b> The general principle behind these rules is that HTTP/1.1 servers and clients ought to transmit as much non-redundant information
    932             as is available in their responses and requests. HTTP/1.1 systems receiving this information will make the most conservative
    933             assumptions about the validators they receive.
    934          </li>
    935          <li>HTTP/1.0 clients and caches might ignore entity-tags. Generally, last-modified values received or used by these systems will
    936             support transparent and efficient caching, and so HTTP/1.1 origin servers still ought to provide Last-Modified values.
    937          </li>
    938       </ul>
    939928      <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="header.field.definitions" href="#header.field.definitions">Precondition Header Fields</a></h1>
    940       <p id="rfc.section.3.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields for applying preconditions on requests. <a href="#precedence" title="Precedence">Section&nbsp;5</a> defines the order of evaluation when more than one precondition is present in a request.
     929      <p id="rfc.section.3.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields for applying preconditions on requests. <a href="#precedence" title="Evaluation and Precedence">Section&nbsp;5</a> defines when the preconditions are applied and the order of evaluation when more than one precondition is present.
    941930      </p>
    942931      <div id="rfc.iref.i.1"></div>
    … …  
    953942         of the selected representation for the target resource (as per <a href="#entity.tag.comparison" title="Comparison">Section&nbsp;2.3.2</a>), or if "*" is given and any current representation exists for the target resource.
    954943      </p>
    955       <p id="rfc.section.3.1.p.5">If the condition is met, the server <em class="bcp14">MAY</em> perform the request method as if the If-Match header field was not present.
     944      <p id="rfc.section.3.1.p.5">If the condition is met, the server <em class="bcp14">MAY</em> perform the request method.
    956945      </p>
    957946      <p id="rfc.section.3.1.p.6">Origin servers <em class="bcp14">MUST NOT</em> perform the requested method if the condition is not met; instead they <em class="bcp14">MUST</em> respond with the <a href="#status.412" class="smpl">412 (Precondition
    … …  
    960949      <p id="rfc.section.3.1.p.7">Proxy servers using a cached response as the selected representation <em class="bcp14">MUST NOT</em> perform the requested method if the condition is not met; instead, they <em class="bcp14">MUST</em> forward the request towards the origin server.
    961950      </p>
    962       <p id="rfc.section.3.1.p.8">If the request would, without the If-Match header field, result in anything other than a <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> or <a href="#status.412" class="smpl">412 (Precondition Failed)</a> status code, then the If-Match header field <em class="bcp14">MUST</em> be ignored.
    963       </p>
    964       <p id="rfc.section.3.1.p.9">Examples:</p>
     951      <p id="rfc.section.3.1.p.8">Examples:</p>
    965952      <div id="rfc.figure.u.9"></div><pre class="text">  If-Match: "xyzzy"
    966953  If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
    … …  
    986973      </p>
    987974      <p id="rfc.section.3.2.p.6">If the condition is not met, the server <em class="bcp14">MUST NOT</em> perform the requested method. Instead, if the request method was GET or HEAD, the server <em class="bcp14">SHOULD</em> respond with a <a href="#status.304" class="smpl">304 (Not Modified)</a> status code, including the cache-related header fields (particularly <a href="#header.etag" class="smpl">ETag</a>) of the selected representation that has a matching entity-tag. For all other request methods, the server <em class="bcp14">MUST</em> respond with a <a href="#status.412" class="smpl">412 (Precondition
    988             Failed)</a> status code.
    989       </p>
    990       <p id="rfc.section.3.2.p.7">If the condition is met, the server <em class="bcp14">MAY</em> perform the requested method as if the If-None-Match header field did not exist, but <em class="bcp14">MUST</em> also ignore any <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a> header field(s) in the request. That is, if no entity-tags match, then the server <em class="bcp14">MUST NOT</em> send a <a href="#status.304" class="smpl">304
    991             (Not Modified)</a> response.
    992       </p>
    993       <p id="rfc.section.3.2.p.8">If the request would, without the If-None-Match header field, result in anything other than a <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> or <a href="#status.304" class="smpl">304 (Not Modified)</a> status code, then the If-None-Match header field <em class="bcp14">MUST</em> be ignored. (See <a href="#rules.for.when.to.use.entity.tags.and.last-modified.dates" title="Rules for When to Use Entity-tags and Last-Modified Dates">Section&nbsp;2.4</a> for a discussion of server behavior when both <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a> and If-None-Match appear in the same request.)
    994       </p>
    995       <p id="rfc.section.3.2.p.9">Examples:</p>
     975            Failed)</a> status code when the condition is not met.
     976      </p>
     977      <p id="rfc.section.3.2.p.7">If the condition is met, the server <em class="bcp14">MAY</em> perform the requested method and <em class="bcp14">MUST</em> ignore any <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a> header field(s) in the request. That is, if no entity-tags match, then the server <em class="bcp14">MUST NOT</em> send a <a href="#status.304" class="smpl">304 (Not Modified)</a> response.
     978      </p>
     979      <p id="rfc.section.3.2.p.8">Examples:</p>
    996980      <div id="rfc.figure.u.11"></div><pre class="text">  If-None-Match: "xyzzy"
    997981  If-None-Match: W/"xyzzy"
    … …  
    10441028      <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>
    10451029      <p id="rfc.section.3.4.p.1">The "If-Unmodified-Since" header field can be used to make a request method conditional by modification date: if the selected
    1046          representation has been modified since the time specified in this field, then the server <em class="bcp14">MUST NOT</em> perform the requested operation and <em class="bcp14">MUST</em> instead respond with the <a href="#status.412" class="smpl">412 (Precondition Failed)</a> status code. If the selected representation has not been modified since the time specified in this field, the server <em class="bcp14">SHOULD</em> perform the request method as if the If-Unmodified-Since header field were not present.
     1030         representation has been modified since the time specified in this field, then the server <em class="bcp14">MUST NOT</em> perform the requested operation and <em class="bcp14">MUST</em> instead respond with the <a href="#status.412" class="smpl">412 (Precondition Failed)</a> status code. If the selected representation has not been modified since the time specified in this field, the server <em class="bcp14">MAY</em> perform the request.
    10471031      </p>
    10481032      <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.10"></span>  <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> = <a href="#imported.abnf" class="smpl">HTTP-date</a>
    10491033</pre><p id="rfc.section.3.4.p.3">An example of the field is:</p>
    10501034      <div id="rfc.figure.u.15"></div><pre class="text">  If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
    1051 </pre><p id="rfc.section.3.4.p.5">If a request normally (i.e., in absence of the If-Unmodified-Since header field) would result in anything other than a <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> or <a href="#status.412" class="smpl">412 (Precondition Failed)</a> status code, the If-Unmodified-Since header field <em class="bcp14">SHOULD</em> be ignored.
    1052       </p>
    1053       <p id="rfc.section.3.4.p.6">If the specified date is invalid, the header field <em class="bcp14">MUST</em> be ignored.
     1035</pre><p id="rfc.section.3.4.p.5">A server <em class="bcp14">MUST</em> ignore the If-Unmodified-Since header field if the received value is not a valid HTTP-date.
    10541036      </p>
    10551037      <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a>&nbsp;<a id="header.if-range" href="#header.if-range">If-Range</a></h2>
    … …  
    10801062         and metadata) and thus prevent the request method from being applied if the target resource is in an unexpected state.
    10811063      </p>
    1082       <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="precedence" href="#precedence">Precedence</a></h1>
    1083       <p id="rfc.section.5.p.1">When more than one conditional request header field is present in a request, the order in which the fields are evaluated becomes
     1064      <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="precedence" href="#precedence">Evaluation and Precedence</a></h1>
     1065      <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
     1066         perform the action associated with the request method). Preconditions are ignored if the server determines that an error or
     1067         redirect response applies before they are evaluated.
     1068      </p>
     1069      <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
    10841070         important. In practice, the fields defined in this document are consistently implemented in a single, logical order, due to
    10851071         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.
    10861072      </p>
    1087       <p id="rfc.section.5.p.2">The general rule of conditional precedence is that exact match conditions are evaluated before cache-validating conditions
     1073      <p id="rfc.section.5.p.3">The general rule of conditional precedence is that exact match conditions are evaluated before cache-validating conditions
    10881074         and, within that order, last-modified conditions are only evaluated if the corresponding entity tag condition is not present
    10891075         (or not applicable because the selected representation does not have an entity tag).
    10901076      </p>
    1091       <p id="rfc.section.5.p.3">Specifically, the fields defined by this specification are evaluated as follows: </p>
     1077      <p id="rfc.section.5.p.4">Specifically, the fields defined by this specification are evaluated as follows: </p>
    10921078      <ol>
    10931079         <li>When <a href="#header.if-match" class="smpl">If-Match</a> is present, evaluate it:
    … …  
    11231109         </li>
    11241110      </ol>
    1125       <p id="rfc.section.5.p.4">Any extension to HTTP/1.1 that defines additional conditional request header fields ought to define its own expectations regarding
     1111      <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
    11261112         the order for evaluating such fields in relation to those defined in this document and other conditionals that might be found
    11271113         in practice.
    … …  
    13051291         situations (such as a PUT response). (<a href="#header.etag" id="rfc.xref.header.etag.4" title="ETag">Section&nbsp;2.3</a>)
    13061292      </p>
    1307       <p id="rfc.section.A.p.5">The precedence for evaluation of conditional requests has been defined. (<a href="#precedence" title="Precedence">Section&nbsp;5</a>)
     1293      <p id="rfc.section.A.p.5">The precedence for evaluation of conditional requests has been defined. (<a href="#precedence" title="Evaluation and Precedence">Section&nbsp;5</a>)
    13081294      </p>
    13091295      <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="imported.abnf" href="#imported.abnf">Imported ABNF</a></h1>
Note: See TracChangeset for help on using the changeset viewer.