Changeset 2128


Ignore:
Timestamp:
Jan 19, 2013, 5:53:26 AM (6 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

Location:
draft-ietf-httpbis/latest
Files:
2 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>
  • draft-ietf-httpbis/latest/p4-conditional.xml

    r2105 r2128  
    209209</t>
    210210<t>
    211    A "strong validator" is a representation metadata value that &MUST; be
     211   A "strong validator" is a representation metadata value that is
    212212   changed to a new, previously unused or guaranteed unique, value whenever
    213213   a change occurs to the representation data such that a change would be
     
    215215</t>
    216216<t>   
    217    A strong validator &MAY; be changed for other reasons, such as when a semantically
     217   A strong validator might change for other reasons, such as when a semantically
    218218   significant part of the representation metadata is changed (e.g.,
    219219   <x:ref>Content-Type</x:ref>), but it is in the best interests of the origin
    220220   server to only change the value when it is necessary to invalidate the
    221221   stored responses held by remote caches and authoring tools.  A strong
    222    validator &MUST; be unique across all representations of a given resource,
     222   validator is unique across all representations of a given resource,
    223223   such that no two representations of that resource share the same validator
    224224   unless their payload body would be identical.
     
    228228   of expiration times.  Thus, a cache might attempt to validate an
    229229   entry using a validator that it obtained in the distant past.
    230    A strong validator &MUST; be unique across all versions of all
     230   A strong validator is unique across all versions of all
    231231   representations associated with a particular resource over time.
    232232   However, there is no implication of uniqueness across representations
     
    453453   for a representation and the generation of that entity-tag does not satisfy
    454454   the requirements for a strong validator
    455    (<xref target="weak.and.strong.validators"/>), then that
    456    entity-tag &MUST; be marked as weak by prefixing its opaque value
     455   (<xref target="weak.and.strong.validators"/>), then the origin server
     456   &MUST; mark the entity-tag as weak by prefixing its opaque value
    457457   with "W/" (case-sensitive).
    458458</t>
     
    489489<section title="Comparison" anchor="entity.tag.comparison">
    490490  <x:anchor-alias value="validator.comparison"/>
     491  <x:anchor-alias value="strong comparison"/>
     492  <x:anchor-alias value="weak comparison"/>
    491493<t>
    492494   There are two entity-tag comparison functions, depending
     
    494496   or not:
    495497  <list style="symbols">
    496      <t>The strong comparison function: in order to be considered equal,
    497         both opaque-tags &MUST; be identical character-by-character, and both
    498         &MUST-NOT; be weak.</t>
    499      <t>The weak comparison function: in order to be considered equal, both
    500         opaque-tags &MUST; be identical character-by-character, but
    501         either or both of them &MAY; be tagged as "weak" without affecting
    502         the result.</t>
     498     <t><x:dfn>Strong comparison</x:dfn>: two entity-tags are equivalent if both
     499        are not weak and their opaque-tags match character-by-character.</t>
     500     <t><x:dfn>Weak comparison</x:dfn>: two entity-tags are equivalent if their opaque-tags
     501        match character-by-character, regardless of either or both
     502        being tagged as "weak".</t>
    503503  </list>
    504504</t>
     
    591591</section>
    592592
    593 <section title="Rules for When to Use Entity-tags and Last-Modified Dates" anchor="rules.for.when.to.use.entity.tags.and.last-modified.dates">
     593<section title="When to Use Entity-tags and Last-Modified Dates" anchor="when.to.use.entity.tags.and.last-modified.dates">
    594594<t>
    595595   We adopt a set of rules and recommendations for origin servers,
     
    598598</t>
    599599<t>
    600    HTTP/1.1 origin servers:
     600   In <x:ref>200 (OK)</x:ref> responses to GET or HEAD, an origin server:
    601601  <list style="symbols">
    602602     <t>&SHOULD; send an entity-tag validator unless it is not feasible to
     
    612612</t>
    613613<t>
    614    In other words, the preferred behavior for an HTTP/1.1 origin server
    615    is to send both a strong entity-tag and a <x:ref>Last-Modified</x:ref> value.
    616 </t>
    617 <t>
    618    HTTP/1.1 clients:
     614   In other words, the preferred behavior for an origin server
     615   is to send both a strong entity-tag and a <x:ref>Last-Modified</x:ref>
     616   value in successful responses to a retrieval request.
     617</t>
     618<t>
     619   A client:
    619620  <list style="symbols">
    620621     <t>&MUST; use that entity-tag in any cache-conditional request (using
     
    638639  </list>
    639640</t>
    640 <t>
    641    An HTTP/1.1 origin server, upon receiving a conditional request that
    642    includes both a Last-Modified date (e.g., in an <x:ref>If-Modified-Since</x:ref>
    643    or <x:ref>If-Unmodified-Since</x:ref> header field) and one or more
    644    entity-tags (e.g., in an <x:ref>If-Match</x:ref>, <x:ref>If-None-Match</x:ref>,
    645    or <x:ref>If-Range</x:ref> header field) as cache validators, &MUST-NOT;
    646    send a response status code of <x:ref>304 (Not Modified)</x:ref> unless
    647    doing so is consistent with all of the conditional header fields in the
    648    request.
    649 </t>
    650 <t>
    651    An HTTP/1.1 caching proxy, upon receiving a conditional request that
    652    includes both a Last-Modified date and one or more entity-tags as
    653    cache validators, &MUST-NOT; send a locally cached response to the
    654    client unless that cached response is consistent with all of the
    655    conditional header fields in the request.
    656   <list><t>
    657       &Note; The general principle behind these rules is that HTTP/1.1
    658       servers and clients ought to transmit as much non-redundant
    659       information as is available in their responses and requests.
    660       HTTP/1.1 systems receiving this information will make the most
    661       conservative assumptions about the validators they receive.
    662   </t><t>
    663       HTTP/1.0 clients and caches might ignore entity-tags. Generally,
    664       last-modified values received or used by these systems will
    665       support transparent and efficient caching, and so HTTP/1.1 origin
    666       servers still ought to provide Last-Modified values.
    667   </t></list>
    668 </t>
    669641</section>
    670642</section>
     
    674646   This section defines the syntax and semantics of HTTP/1.1 header fields
    675647   for applying preconditions on requests.
    676    <xref target="precedence"/> defines the order of evaluation when
    677    more than one precondition is present in a request.
     648   <xref target="precedence"/> defines when the preconditions are applied and
     649   the order of evaluation when more than one precondition is present.
    678650</t>
    679651
     
    705677</t>
    706678<t>
    707    If the condition is met, the server &MAY; perform the request method as if
    708    the If-Match header field was not present.
     679   If the condition is met, the server &MAY; perform the request method.
    709680</t>
    710681<t>
     
    717688   &MUST-NOT; perform the requested method if the condition is not met;
    718689   instead, they &MUST; forward the request towards the origin server.
    719 </t>
    720 <t>
    721    If the request would, without the If-Match header field, result in
    722    anything other than a <x:ref>2xx (Successful)</x:ref> or <x:ref>412 (Precondition Failed)</x:ref>
    723    status code, then the If-Match header field &MUST; be ignored.
    724690</t>
    725691<t>
     
    775741   selected representation that has a matching entity-tag. For all other
    776742   request methods, the server &MUST; respond with a <x:ref>412 (Precondition
    777    Failed)</x:ref> status code.
    778 </t>
    779 <t>
    780    If the condition is met, the server &MAY; perform the requested method
    781    as if the If-None-Match header field did not exist, but &MUST; also ignore
    782    any <x:ref>If-Modified-Since</x:ref> header field(s) in the request. That
    783    is, if no entity-tags match, then the server &MUST-NOT; send a <x:ref>304
    784    (Not Modified)</x:ref> response.
    785 </t>
    786 <t>
    787    If the request would, without the If-None-Match header field, result
    788    in anything other than a <x:ref>2xx (Successful)</x:ref> or
    789    <x:ref>304 (Not Modified)</x:ref> status code, then the If-None-Match
    790    header field &MUST; be ignored. (See <xref
    791    target="rules.for.when.to.use.entity.tags.and.last-modified.dates"/> for
    792    a discussion of server behavior when both <x:ref>If-Modified-Since</x:ref>
    793    and If-None-Match appear in the same request.)
     743   Failed)</x:ref> status code when the condition is not met.
     744</t>
     745<t>
     746   If the condition is met, the server &MAY; perform the requested method and
     747   &MUST; ignore any <x:ref>If-Modified-Since</x:ref> header field(s) in the
     748   request. That is, if no entity-tags match, then the server &MUST-NOT; send
     749   a <x:ref>304 (Not Modified)</x:ref> response.
    794750</t>
    795751<t>
     
    897853   respond with the <x:ref>412 (Precondition Failed)</x:ref> status code.
    898854   If the selected representation has not been modified since the time
    899    specified in this field, the server &SHOULD; perform the request
    900    method as if the If-Unmodified-Since header field were not present.
     855   specified in this field, the server &MAY; perform the request.
    901856</t>
    902857<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-Unmodified-Since"/>
     
    910865</artwork></figure>
    911866<t>
    912    If a request normally (i.e., in absence of the If-Unmodified-Since
    913    header field) would result in anything other than a <x:ref>2xx (Successful)</x:ref>
    914    or <x:ref>412 (Precondition Failed)</x:ref> status code,
    915    the If-Unmodified-Since header field &SHOULD; be ignored.
    916 </t>
    917 <t>
    918    If the specified date is invalid, the header field &MUST; be ignored.
     867   A server &MUST; ignore the If-Unmodified-Since header field if the
     868   received value is not a valid HTTP-date.
    919869</t>
    920870</section>
     
    982932  <x:anchor-alias value="412 (Precondition Failed)"/>
    983933<t>
    984    The <x:dfn>412 (Precondition Failed)</x:dfn> status code indicates that one or more preconditions given in
    985    the request header fields evaluated to false when tested on the server.
    986    This response code allows the client to place preconditions on the
    987    current resource state (its current representations and metadata)
    988    and thus prevent the request method from being applied if the target
    989    resource is in an unexpected state.
    990 </t>
    991 </section>
    992 </section>
    993 
    994 <section title="Precedence" anchor="precedence">
     934   The <x:dfn>412 (Precondition Failed)</x:dfn> status code indicates that one
     935   or more preconditions given in the request header fields evaluated to false
     936   when tested on the server. This response code allows the client to place
     937   preconditions on the current resource state (its current representations
     938   and metadata) and thus prevent the request method from being applied if the
     939   target resource is in an unexpected state.
     940</t>
     941</section>
     942</section>
     943
     944<section title="Evaluation and Precedence" anchor="precedence">
     945<t>
     946   For each conditional request, a server &MUST; evaluate the request
     947   preconditions after it has successfully performed its normal request checks
     948   (i.e., just before it would perform the action associated with the request
     949   method). Preconditions are ignored if the server determines that an error
     950   or redirect response applies before they are evaluated.
     951</t>
    995952<t>
    996953   When more than one conditional request header field is present in a request,
     
    999956   single, logical order, due to the fact that entity tags are presumed to be
    1000957   more accurate than date validators. For example, the only reason to send
    1001    both <x:ref>If-Modified-Since</x:ref> and <x:ref>If-None-Match</x:ref> in the same GET request is to
    1002    support intermediary caches that might not have implemented <x:ref>If-None-Match</x:ref>,
    1003    so it makes sense to ignore the <x:ref>If-Modified-Since</x:ref> when entity tags are
    1004    understood and available for the selected representation.
     958   both <x:ref>If-Modified-Since</x:ref> and <x:ref>If-None-Match</x:ref> in
     959   the same GET request is to support intermediary caches that might not have
     960   implemented <x:ref>If-None-Match</x:ref>, so it makes sense to ignore the
     961   <x:ref>If-Modified-Since</x:ref> when entity tags are understood and
     962   available for the selected representation.
    1005963</t>
    1006964<t>
Note: See TracChangeset for help on using the changeset viewer.