Changeset 2361


Ignore:
Timestamp:
23/08/13 13:20:09 (9 years ago)
Author:
fielding@…
Message:

Rephrase conditional header field definitions, again, to remove all untargeted requirements and clarify that only origin servers and recipient caches need to evaluate; make the precedence order a requirement; addresses #479

Location:
draft-ietf-httpbis/latest
Files:
2 edited

Legend:

Unmodified
Added
Removed

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

    r2358 r2361  
    449449  }
    450450  @bottom-center {
    451        content: "Expires February 13, 2014";
     451       content: "Expires February 24, 2014";
    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 Evaluation and Precedence" href="#rfc.section.5">
    478       <link rel="Chapter" title="6 IANA Considerations" href="#rfc.section.6">
    479       <link rel="Chapter" title="7 Security Considerations" href="#rfc.section.7">
    480       <link rel="Chapter" title="8 Acknowledgments" href="#rfc.section.8">
    481       <link rel="Chapter" href="#rfc.section.9" title="9 References">
     477      <link rel="Chapter" title="5 Evaluation" href="#rfc.section.5">
     478      <link rel="Chapter" title="6 Precedence" href="#rfc.section.6">
     479      <link rel="Chapter" title="7 IANA Considerations" href="#rfc.section.7">
     480      <link rel="Chapter" title="8 Security Considerations" href="#rfc.section.8">
     481      <link rel="Chapter" title="9 Acknowledgments" href="#rfc.section.9">
     482      <link rel="Chapter" href="#rfc.section.10" title="10 References">
    482483      <link rel="Appendix" title="A Changes from RFC 2616" href="#rfc.section.A">
    483484      <link rel="Appendix" title="B Imported ABNF" href="#rfc.section.B">
    … …  
    491492      <meta name="dct.creator" content="Reschke, J. F.">
    492493      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest">
    493       <meta name="dct.issued" scheme="ISO8601" content="2013-08-12">
     494      <meta name="dct.issued" scheme="ISO8601" content="2013-08-23">
    494495      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    495496      <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.">
    … …  
    517518            </tr>
    518519            <tr>
    519                <td class="left">Expires: February 13, 2014</td>
    520                <td class="right">August 12, 2013</td>
     520               <td class="left">Expires: February 24, 2014</td>
     521               <td class="right">August 23, 2013</td>
    521522            </tr>
    522523         </tbody>
    … …  
    545546         in progress”.
    546547      </p>
    547       <p>This Internet-Draft will expire on February 13, 2014.</p>
     548      <p>This Internet-Draft will expire on February 24, 2014.</p>
    548549      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    549550      <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    584585            </ul>
    585586         </li>
    586          <li><a href="#rfc.section.3">3.</a>&nbsp;&nbsp;&nbsp;<a href="#header.field.definitions">Precondition Header Fields</a><ul>
     587         <li><a href="#rfc.section.3">3.</a>&nbsp;&nbsp;&nbsp;<a href="#preconditions">Precondition Header Fields</a><ul>
    587588               <li><a href="#rfc.section.3.1">3.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.if-match">If-Match</a></li>
    588589               <li><a href="#rfc.section.3.2">3.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.if-none-match">If-None-Match</a></li>
    … …  
    597598            </ul>
    598599         </li>
    599          <li><a href="#rfc.section.5">5.</a>&nbsp;&nbsp;&nbsp;<a href="#precedence">Evaluation and Precedence</a></li>
    600          <li><a href="#rfc.section.6">6.</a>&nbsp;&nbsp;&nbsp;<a href="#IANA.considerations">IANA Considerations</a><ul>
    601                <li><a href="#rfc.section.6.1">6.1</a>&nbsp;&nbsp;&nbsp;<a href="#status.code.registration">Status Code Registration</a></li>
    602                <li><a href="#rfc.section.6.2">6.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.field.registration">Header Field Registration</a></li>
     600         <li><a href="#rfc.section.5">5.</a>&nbsp;&nbsp;&nbsp;<a href="#evaluation">Evaluation</a></li>
     601         <li><a href="#rfc.section.6">6.</a>&nbsp;&nbsp;&nbsp;<a href="#precedence">Precedence</a></li>
     602         <li><a href="#rfc.section.7">7.</a>&nbsp;&nbsp;&nbsp;<a href="#IANA.considerations">IANA Considerations</a><ul>
     603               <li><a href="#rfc.section.7.1">7.1</a>&nbsp;&nbsp;&nbsp;<a href="#status.code.registration">Status Code Registration</a></li>
     604               <li><a href="#rfc.section.7.2">7.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.field.registration">Header Field Registration</a></li>
    603605            </ul>
    604606         </li>
    605          <li><a href="#rfc.section.7">7.</a>&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a></li>
    606          <li><a href="#rfc.section.8">8.</a>&nbsp;&nbsp;&nbsp;<a href="#acks">Acknowledgments</a></li>
    607          <li><a href="#rfc.section.9">9.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a><ul>
    608                <li><a href="#rfc.section.9.1">9.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.1">Normative References</a></li>
    609                <li><a href="#rfc.section.9.2">9.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.2">Informative References</a></li>
     607         <li><a href="#rfc.section.8">8.</a>&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a></li>
     608         <li><a href="#rfc.section.9">9.</a>&nbsp;&nbsp;&nbsp;<a href="#acks">Acknowledgments</a></li>
     609         <li><a href="#rfc.section.10">10.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a><ul>
     610               <li><a href="#rfc.section.10.1">10.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.1">Normative References</a></li>
     611               <li><a href="#rfc.section.10.2">10.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.2">Informative References</a></li>
    610612            </ul>
    611613         </li>
    … …  
    639641         to false.
    640642      </p>
    641       <p id="rfc.section.1.p.4">The conditional request preconditions defined by this specification are evaluated by comparing the validators provided in
    642          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>.
     643      <p id="rfc.section.1.p.4">The conditional request preconditions defined by this specification (<a href="#preconditions" title="Precondition Header Fields">Section&nbsp;3</a>) are evaluated when applicable to the recipient (<a href="#evaluation" title="Evaluation">Section&nbsp;5</a>) according to their order of precedence (<a href="#precedence" title="Precedence">Section&nbsp;6</a>).
    643644      </p>
    644645      <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>
    … …  
    932933         </li>
    933934      </ul>
    934       <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>
    935       <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.
     935      <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="preconditions" href="#preconditions">Precondition Header Fields</a></h1>
     936      <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="#evaluation" title="Evaluation">Section&nbsp;5</a> defines when the preconditions are applied. <a href="#precedence" title="Precedence">Section&nbsp;6</a> defines the order of evaluation when more than one precondition is present.
    936937      </p>
    937938      <div id="rfc.iref.i.1"></div>
    938939      <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a id="header.if-match" href="#header.if-match">If-Match</a></h2>
    939       <p id="rfc.section.3.1.p.1">The "If-Match" header field makes the request method conditional on either the existence of a current representation for the
    940          target resource, when the field-value is "*", or on the selected representation having an entity-tag that matches one of those
    941          provided in the field-value.
     940      <p id="rfc.section.3.1.p.1">The "If-Match" header field makes the request method conditional on the recipient cache or origin server either having at
     941         least one current representation of the target resource, when the field-value is "*", or having a current representation of
     942         the target resource that has an entity-tag matching a member of the list of entity-tags provided in the field-value. A recipient <em class="bcp14">MUST</em> use the strong comparison function when comparing entity-tags for If-Match (<a href="#entity.tag.comparison" title="Comparison">Section&nbsp;2.3.2</a>).
    942943      </p>
    943944      <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.7"></span>  <a href="#header.if-match" class="smpl">If-Match</a> = "*" / 1#<a href="#header.etag" class="smpl">entity-tag</a>
    … …  
    946947  If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
    947948  If-Match: *
    948 </pre><p id="rfc.section.3.1.p.5">If the request semantics (method and header fields) allow the request to be satisfied with a cached response, a cache <em class="bcp14">SHOULD</em> evaluate the condition based on its currently stored set of suitable responses for that request (see <a href="p6-cache.html#constructing.responses.from.caches" title="Constructing Responses from Caches">Section 4</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). If the field-value is "*" and any suitable response is currently stored, or if the field-value is a list of entity-tag
    949          values and at least one of the suitable responses has an <a href="#header.etag" class="smpl">ETag</a> header field with a value matching an entity-tag in that list, then the cache <em class="bcp14">SHOULD</em> reuse the most suitable of those matching responses to satisfy the request. If the condition is not met, none of the cached
    950          responses is suitable for reuse in response to this request.
    951       </p>
    952       <p id="rfc.section.3.1.p.6">If the request semantics cannot be satisfied with a cached response, the conditional is only evaluated when received by an
    953          origin server. For example, If-Match is most often used with state-changing requests, such as PUT, to prevent accidental overwrites
    954          when multiple user agents might be acting in parallel on the same resource (i.e., to prevent the "lost update" problem).
    955       </p>
    956       <p id="rfc.section.3.1.p.7">When the If-Match field-value consists of a list of entity-tag values, the condition is met if any of the entity-tags listed
    957          match, using the weak comparison function (as per <a href="#entity.tag.comparison" title="Comparison">Section&nbsp;2.3.2</a>), the entity-tag of the selected representation. When the If-Match field-value is "*", the condition is met if any current
    958          representation exists for the target resource.
    959       </p>
    960       <p id="rfc.section.3.1.p.8">If the condition is met, the origin server <em class="bcp14">MAY</em> perform the requested method.
    961       </p>
    962       <p id="rfc.section.3.1.p.9">An origin server <em class="bcp14">MUST NOT</em> perform the requested method if the condition is not met; instead the origin server <em class="bcp14">MUST</em> respond with either: a) the <a href="#status.412" class="smpl">412 (Precondition Failed)</a> status code; or, b) one of the <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> status codes if the origin server has verified that a state change is being requested and the final state is already reflected
     949</pre><p id="rfc.section.3.1.p.5">If-Match is most often used with state-changing methods (e.g., POST, PUT, DELETE) to prevent accidental overwrites when multiple
     950         user agents might be acting in parallel on the same resource (i.e., to prevent the "lost update" problem). It can also be
     951         used with safe methods to abort a request if the <a href="p2-semantics.html#representations" class="smpl">selected representation</a> does not match one already stored (or partially stored) from a prior request.
     952      </p>
     953      <p id="rfc.section.3.1.p.6">An origin server that receives an If-Match header field <em class="bcp14">MUST</em> evaluate the condition prior to performing the method (<a href="#evaluation" title="Evaluation">Section&nbsp;5</a>). If the field-value is "*", the condition is false if the origin server does not have a current representation for the target
     954         resource. If the field-value is a list of entity-tags, the condition is false if none of the listed tags match the entity-tag
     955         of the selected representation.
     956      </p>
     957      <p id="rfc.section.3.1.p.7">An origin server <em class="bcp14">MUST NOT</em> perform the requested method if a received If-Match condition evaluates to false; instead the origin server <em class="bcp14">MUST</em> respond with either: a) the <a href="#status.412" class="smpl">412 (Precondition Failed)</a> status code; or, b) one of the <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> status codes if the origin server has verified that a state change is being requested and the final state is already reflected
    963958         in the current state of the target resource (i.e., the change requested by the user agent has already succeeded, but the user
    964          agent might not be aware of that because the prior response message was lost or a compatible change was made by some other
     959         agent might not be aware of it, perhaps because the prior response was lost or a compatible change was made by some other
    965960         user agent). In the latter case, the origin server <em class="bcp14">MUST NOT</em> send a validator header field in the response unless it can verify that the request is a duplicate of an immediately prior
    966961         change made by the same user agent.
    967962      </p>
     963      <p id="rfc.section.3.1.p.8">If the request semantics can be satisfied with a cached response, a recipient cache <em class="bcp14">MUST</em> evaluate the condition as part of its selection process for determining a suitable response for that primary cache key (see <a href="p6-cache.html#constructing.responses.from.caches" title="Constructing Responses from Caches">Section 4</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). The cache <em class="bcp14">MUST</em> generate a <a href="#status.412" class="smpl">412 (Precondition Failed)</a> response if the field-value is "*" and no suitable response is stored, or if the field-value is a list of entity-tags and
     964         none of them match the entity-tag of a suitable stored response. Otherwise, the cache <em class="bcp14">MUST</em> generate a successful <a href="p2-semantics.html#status.2xx" class="smpl">2xx</a> response that reuses the most recent of its matching stored responses to satisfy the request.
     965      </p>
    968966      <div id="rfc.iref.i.2"></div>
    969967      <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="header.if-none-match" href="#header.if-none-match">If-None-Match</a></h2>
    970       <p id="rfc.section.3.2.p.1">The "If-None-Match" header field can be used to make a request method conditional on not matching any of the current entity-tag
    971          values for representations of the target resource.
    972       </p>
    973       <p id="rfc.section.3.2.p.2">If-None-Match is primarily used in conditional GET requests to enable efficient updates of cached information with a minimum
    974          amount of transaction overhead. A client that has one or more representations previously obtained from the target resource
    975          can send If-None-Match with a list of the associated entity-tags in the hope of receiving a <a href="#status.304" class="smpl">304 (Not
    976             Modified)</a> response if at least one of those representations matches the selected representation.
    977       </p>
    978       <p id="rfc.section.3.2.p.3">If-None-Match can also be used with a value of "*" to prevent an unsafe request method (e.g., PUT) from inadvertently modifying
    979          an existing representation of the target resource when the client believes that the resource does not have a current representation
    980          (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 4.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). This is a variation on the "lost update" problem that might arise if more than one client attempts to create an initial
    981          representation for the target resource.
     968      <p id="rfc.section.3.2.p.1">The "If-None-Match" header field makes the request method conditional on the recipient cache or origin server either not having
     969         a current representation for the target resource, when the field-value is "*", or not having a current representation that
     970         has an entity-tag matching a member of the list of entity-tags provided in the field-value. A recipient <em class="bcp14">MUST</em> use the weak comparison function when comparing entity-tags for If-None-Match (<a href="#entity.tag.comparison" title="Comparison">Section&nbsp;2.3.2</a>).
    982971      </p>
    983972      <div id="rfc.figure.u.10"></div><pre class="inline"><span id="rfc.iref.g.8"></span>  <a href="#header.if-none-match" class="smpl">If-None-Match</a> = "*" / 1#<a href="#header.etag" class="smpl">entity-tag</a>
    984 </pre><p id="rfc.section.3.2.p.5">The If-None-Match condition is met if and only if none of the entity-tags listed in the If-None-Match field value match the
    985          entity-tag of the selected representation using the weak comparison function (as per <a href="#entity.tag.comparison" title="Comparison">Section&nbsp;2.3.2</a>), or if "*" is given and no current representation exists for that resource.
    986       </p>
    987       <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 when the condition is not met.
    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 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.
    991       </p>
    992       <p id="rfc.section.3.2.p.8">Examples:</p>
     973</pre><p id="rfc.section.3.2.p.3">Examples:</p>
    993974      <div id="rfc.figure.u.11"></div><pre class="text">  If-None-Match: "xyzzy"
    994975  If-None-Match: W/"xyzzy"
    … …  
    996977  If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
    997978  If-None-Match: *
    998 </pre><div id="rfc.iref.i.3"></div>
     979</pre><p id="rfc.section.3.2.p.5">If-None-Match is primarily used in conditional GET requests to enable efficient updates of cached information with a minimum
     980         amount of transaction overhead. When a client desires to update one or more stored responses that have entity-tags, the client <em class="bcp14">SHOULD</em> generate an If-None-Match header field containing a list of those entity-tags when making a GET request; this allows recipient
     981         servers to send a <a href="#status.304" class="smpl">304 (Not Modified)</a> response to indicate when one of those stored responses matches the selected representation.
     982      </p>
     983      <p id="rfc.section.3.2.p.6">If-None-Match can also be used with a value of "*" to prevent an unsafe request method (e.g., PUT) from inadvertently modifying
     984         an existing representation of the target resource when the client believes that the resource does not have a current representation
     985         (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 4.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). This is a variation on the "lost update" problem that might arise if more than one client attempts to create an initial
     986         representation for the target resource.
     987      </p>
     988      <p id="rfc.section.3.2.p.7">An origin server that receives an If-None-Match header field <em class="bcp14">MUST</em> evaluate the condition prior to performing the method (<a href="#evaluation" title="Evaluation">Section&nbsp;5</a>). If the field-value is "*", the condition is false if the origin server has a current representation for the target resource.
     989         If the field-value is a list of entity-tags, the condition is false if one of the listed tags match the entity-tag of the
     990         selected representation.
     991      </p>
     992      <p id="rfc.section.3.2.p.8">An origin server <em class="bcp14">MUST NOT</em> perform the requested method if the condition evaluates to false; instead, the origin server <em class="bcp14">MUST</em> respond with either a) the <a href="#status.304" class="smpl">304 (Not Modified)</a> status code if the request method is GET or HEAD; or, b) the <a href="#status.412" class="smpl">412 (Precondition Failed)</a> status code for all other request methods.
     993      </p>
     994      <p id="rfc.section.3.2.p.9">If the request semantics can be satisfied with a cached response, a recipient cache <em class="bcp14">SHOULD</em> evaluate the condition as part of its selection process for determining a suitable response for that primary cache key (see <a href="p6-cache.html#constructing.responses.from.caches" title="Constructing Responses from Caches">Section 4</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). If the field-value is "*" and a suitable response is stored, or the field-value is a list of entity-tags and at least one
     995         of them match the entity-tag of a suitable stored response, the cache <em class="bcp14">SHOULD</em> generate a <a href="#status.304" class="smpl">304 (Not Modified)</a> response using the most suitable of those matching responses as the selected representation. Otherwise, if the cache has one
     996         or more suitable stored responses that do not match the condition, the cache <em class="bcp14">SHOULD</em> generate a successful <a href="p2-semantics.html#status.2xx" class="smpl">2xx</a> response that reuses the most suitable of those stored responses to satisfy the request. Finally, if the cache has no suitable
     997         stored responses, the cache <em class="bcp14">SHOULD</em> forward the conditional request toward the origin server; if the received condition contains a list of entity-tags and the
     998         cache has its own set of stored responses for that primary cache key, the cache <em class="bcp14">SHOULD</em> take the union of the received set with the set of entity-tags for its own stored set of responses (fresh or stale) and generate
     999         an <a href="#header.if-none-match" class="smpl">If-None-Match</a> header field containing that union when it forwards the request toward the origin server.
     1000      </p>
     1001      <div id="rfc.iref.i.3"></div>
    9991002      <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a>&nbsp;<a id="header.if-modified-since" href="#header.if-modified-since">If-Modified-Since</a></h2>
    10001003      <p id="rfc.section.3.3.p.1">The "If-Modified-Since" header field can be used with GET or HEAD to make the method conditional by modification date: if
    1001          the selected representation has not been modified since the time specified in this field, then do not perform the request
    1002          method; instead, respond as detailed below.
     1004         the selected representation has not been modified since the time specified in this field, then respond with a <a href="#status.304" class="smpl">304 (Not Modified)</a> status code and only send metadata that might be useful for identifying or updating a cached representation. Hence, transfer
     1005         of the selected representation's data is avoided if that data has not changed.
    10031006      </p>
    10041007      <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.9"></span>  <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a> = <a href="#imported.abnf" class="smpl">HTTP-date</a>
    10051008</pre><p id="rfc.section.3.3.p.3">An example of the field is:</p>
    10061009      <div id="rfc.figure.u.13"></div><pre class="text">  If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
    1007 </pre><p id="rfc.section.3.3.p.5">A GET method with an If-Modified-Since header field and no <a href="p5-range.html#header.range" class="smpl">Range</a> header field requests that the selected representation be transferred only if it has been modified since the date given by
    1008          the If-Modified-Since header field. The algorithm for determining this includes the following cases:
    1009       </p>
    1010       <ol>
    1011          <li>If the request would normally result in anything other than a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> status code, or if the passed If-Modified-Since date is invalid, the response is exactly the same as for a normal GET. A date
    1012             that is later than the server's current time is invalid.
    1013          </li>
    1014          <li>If the selected representation has been modified since the If-Modified-Since date, the response is exactly the same as for
    1015             a normal GET.
    1016          </li>
    1017          <li>If the selected representation has not been modified since a valid If-Modified-Since date, the server <em class="bcp14">SHOULD</em> send a <a href="#status.304" class="smpl">304 (Not Modified)</a> response.
    1018          </li>
    1019       </ol>
    1020       <p id="rfc.section.3.3.p.6">The two purposes of this feature are to allow efficient updates of cached information, with a minimum amount of transaction
    1021          overhead, and to limit the scope of a web traversal to resources that have recently changed.
    1022       </p>
    1023       <p id="rfc.section.3.3.p.7">When used for cache updates, a cache will typically use the value of the cached message's <a href="#header.last-modified" class="smpl">Last-Modified</a> field to generate the field value of If-Modified-Since. This behavior is most interoperable for cases where clocks are poorly
     1010</pre><p id="rfc.section.3.3.p.5">A recipient <em class="bcp14">MUST</em> ignore If-Modified-Since if the request contains an <a href="#header.if-none-match" class="smpl">If-None-Match</a> header field; the condition in <a href="#header.if-none-match" class="smpl">If-None-Match</a> is considered to be a more accurate replacement for the condition in If-Modified-Since and the two are only combined for the
     1011         sake of interoperating with older intermediaries that might not implement <a href="#header.if-none-match" class="smpl">If-None-Match</a>.
     1012      </p>
     1013      <p id="rfc.section.3.3.p.6">A recipient <em class="bcp14">MUST</em> ignore the If-Modified-Since header field if the received field-value is not a valid HTTP-date, or if the request method is
     1014         neither GET nor HEAD.
     1015      </p>
     1016      <p id="rfc.section.3.3.p.7">A recipient <em class="bcp14">MUST</em> interpret an If-Modified-Since field-value's timestamp in terms of the origin server's clock. A recipient cache that evaluates
     1017         this precondition <em class="bcp14">SHOULD</em> make its comparisons with respect to a stored <a href="#header.last-modified" class="smpl">Last-Modified</a> or <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field, when available in a prior response from that origin server, rather than comparing it to a timestamp generated
     1018         by its own clock.
     1019      </p>
     1020      <p id="rfc.section.3.3.p.8">If-Modified-Since is typically used for two distinct purposes: 1) to allow efficient updates of a cached representation that
     1021         does not have an entity-tag; and, 2) to limit the scope of a web traversal to resources that have recently changed.
     1022      </p>
     1023      <p id="rfc.section.3.3.p.9">When used for cache updates, a cache will typically use the value of the cached message's <a href="#header.last-modified" class="smpl">Last-Modified</a> field to generate the field value of If-Modified-Since. This behavior is most interoperable for cases where clocks are poorly
    10241024         synchronized or when the server has chosen to only honor exact timestamp matches (due to a problem with Last-Modified dates
    10251025         that appear to go "back in time" when the origin server's clock is corrected or a representation is restored from an archived
    … …  
    10271027         does not contain a <a href="#header.last-modified" class="smpl">Last-Modified</a> field.
    10281028      </p>
    1029       <p id="rfc.section.3.3.p.8">When used for limiting the scope of retrieval to a recent time window, a user agent will generate an If-Modified-Since field
     1029      <p id="rfc.section.3.3.p.10">When used for limiting the scope of retrieval to a recent time window, a user agent will generate an If-Modified-Since field
    10301030         value based on either its own local clock or a <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field received from the server during a past run. Origin servers that choose an exact timestamp match based on the
    10311031         selected representation's <a href="#header.last-modified" class="smpl">Last-Modified</a> field will not be able to help the user agent limit its data transfers to only those changed during the specified window.
    10321032      </p>
    1033       <div class="note" id="rfc.section.3.3.p.9">
    1034          <p><b>Note:</b> If a client uses an arbitrary date in the If-Modified-Since header field instead of a date taken from a <a href="#header.last-modified" class="smpl">Last-Modified</a> or <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field from the origin server, the client ought to be aware that its date will be interpreted according to the server's
    1035             understanding of time.
    1036          </p>
    1037       </div>
     1033      <p id="rfc.section.3.3.p.11">If the request semantics can be satisfied with a cached response, a recipient cache <em class="bcp14">SHOULD</em> evaluate the condition as part of its selection process for determining a suitable response for that primary cache key (see <a href="p6-cache.html#constructing.responses.from.caches" title="Constructing Responses from Caches">Section 4</a> of <a href="#Part6" id="rfc.xref.Part6.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). The cache <em class="bcp14">SHOULD</em> forward the conditional request toward the origin server if it does not have any suitable stored responses. The cache <em class="bcp14">SHOULD</em> generate a successful <a href="p2-semantics.html#status.2xx" class="smpl">2xx</a> response, reusing the most recent of its stored responses to satisfy the request, if one of the following is true: 1) a stored
     1034         response has a <a href="#header.last-modified" class="smpl">Last-Modified</a> field-value that is more recent than the conditional timestamp; 2) no <a href="#header.last-modified" class="smpl">Last-Modified</a> field is present, but a stored response has a <a href="p2-semantics.html#header.date" class="smpl">Date</a> field-value that is more recent than the conditional timestamp; or, 3) neither <a href="#header.last-modified" class="smpl">Last-Modified</a> nor <a href="p2-semantics.html#header.date" class="smpl">Date</a> is present, but the cache recorded a stored response as having been received at a time more recent than the conditional timestamp.
     1035         Otherwise, the cache <em class="bcp14">SHOULD</em> generate a <a href="#status.304" class="smpl">304 (Not Modified)</a> response using the most recent of the stored responses as the selected representation.
     1036      </p>
    10381037      <div id="rfc.iref.i.4"></div>
    10391038      <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>
    … …  
    10441043</pre><p id="rfc.section.3.4.p.3">An example of the field is:</p>
    10451044      <div id="rfc.figure.u.15"></div><pre class="text">  If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
    1046 </pre><p id="rfc.section.3.4.p.5">A server <em class="bcp14">MUST</em> ignore If-Unmodified-Since if the selected representation has an entity-tag and the request contains an If-Match header field;
    1047          the condition in If-Match, when applicable, is considered to be a more accurate replacement for the condition in If-Unmodified-Since.
    1048       </p>
    1049       <p id="rfc.section.3.4.p.6">A server <em class="bcp14">MUST</em> ignore the If-Unmodified-Since header field if the received field-value is not a valid HTTP-date.
    1050       </p>
    1051       <p id="rfc.section.3.4.p.7">If the request semantics (method and header fields) allow the request to be satisfied with a cached response, a cache <em class="bcp14">SHOULD</em> evaluate the condition based on its currently stored set of suitable responses for that request (see <a href="p6-cache.html#constructing.responses.from.caches" title="Constructing Responses from Caches">Section 4</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). If the most suitable response has a <a href="#header.last-modified" class="smpl">Last-Modified</a> date that is earlier or equal to the date given in If-Unmodified-Since, the cache <em class="bcp14">SHOULD</em> reuse that response to satisfy the request. If the condition is not met, none of the stored responses is suitable for reuse
    1052          in response to this request.
    1053       </p>
    1054       <p id="rfc.section.3.4.p.8">If the request semantics cannot be satisfied with a cached response, the conditional is only evaluated when received by an
    1055          origin server. If the selected representation has not been modified since the time specified in this field, then the condition
    1056          is met.
    1057       </p>
    1058       <p id="rfc.section.3.4.p.9">If the condition is met, the origin server <em class="bcp14">MAY</em> perform the requested method.
    1059       </p>
    1060       <p id="rfc.section.3.4.p.10">An origin server <em class="bcp14">MUST NOT</em> perform the requested method if the condition is not met; instead the origin server <em class="bcp14">MUST</em> respond with either: a) the <a href="#status.412" class="smpl">412 (Precondition Failed)</a> status code; or, b) one of the <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> status codes if the origin server has verified that a state change is being requested and the final state is already reflected
     1045</pre><p id="rfc.section.3.4.p.5">A recipient <em class="bcp14">MUST</em> ignore If-Unmodified-Since if the request contains an <a href="#header.if-match" class="smpl">If-Match</a> header field; the condition in <a href="#header.if-match" class="smpl">If-Match</a> is considered to be a more accurate replacement for the condition in If-Unmodified-Since and the two are only combined for
     1046         the sake of interoperating with older intermediaries that might not implement <a href="#header.if-match" class="smpl">If-Match</a>.
     1047      </p>
     1048      <p id="rfc.section.3.4.p.6">A recipient <em class="bcp14">MUST</em> ignore the If-Unmodified-Since header field if the received field-value is not a valid HTTP-date.
     1049      </p>
     1050      <p id="rfc.section.3.4.p.7">A recipient <em class="bcp14">MUST</em> interpret an If-Unmodified-Since field-value's timestamp in terms of the origin server's clock.
     1051      </p>
     1052      <p id="rfc.section.3.4.p.8">If-Unmodified-Since is most often used with state-changing methods (e.g., POST, PUT, DELETE) to prevent accidental overwrites
     1053         when multiple user agents might be acting in parallel on a resource that resource does not supply entity-tags with its representations
     1054         (i.e., to prevent the "lost update" problem). It can also be used with safe methods to abort a request if the <a href="p2-semantics.html#representations" class="smpl">selected representation</a> does not match one already stored (or partially stored) from a prior request.
     1055      </p>
     1056      <p id="rfc.section.3.4.p.9">An origin server that receives an If-Unmodified-Since header field <em class="bcp14">MUST</em> evaluate the condition prior to performing the method (<a href="#evaluation" title="Evaluation">Section&nbsp;5</a>). The condition is false if the selected representation has been modified since the time specified in this field.
     1057      </p>
     1058      <p id="rfc.section.3.4.p.10">An origin server <em class="bcp14">MUST NOT</em> perform the requested method if a received If-Unmodified-Since condition evaluates to false; instead the origin server <em class="bcp14">MUST</em> respond with either: a) the <a href="#status.412" class="smpl">412 (Precondition Failed)</a> status code; or, b) one of the <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> status codes if the origin server has verified that a state change is being requested and the final state is already reflected
    10611059         in the current state of the target resource (i.e., the change requested by the user agent has already succeeded, but the user
    10621060         agent might not be aware of that because the prior response message was lost or a compatible change was made by some other
    … …  
    10641062         change made by the same user agent.
    10651063      </p>
     1064      <p id="rfc.section.3.4.p.11">If the request semantics can be satisfied with a cached response, a recipient cache <em class="bcp14">MUST</em> evaluate the condition as part of its selection process for determining a suitable response for that primary cache key (see <a href="p6-cache.html#constructing.responses.from.caches" title="Constructing Responses from Caches">Section 4</a> of <a href="#Part6" id="rfc.xref.Part6.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). The cache <em class="bcp14">MUST</em> forward the conditional request toward the origin server if it does not have any suitable stored responses. The cache <em class="bcp14">MUST</em> generate a successful <a href="p2-semantics.html#status.2xx" class="smpl">2xx</a> response that reuses the most recent of its suitable stored responses to satisfy the request if that stored response has a <a href="#header.last-modified" class="smpl">Last-Modified</a> date that is equal to or earlier than the date given in If-Unmodified-Since. Otherwise, the cache <em class="bcp14">MUST</em> respond with a <a href="#status.412" class="smpl">412 (Precondition Failed)</a> status code.
     1065      </p>
    10661066      <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>
    1067       <p id="rfc.section.3.5.p.1">The "If-Range" header field provides a special conditional request mechanism that is similar to <a href="#header.if-match" class="smpl">If-Match</a> and <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> but specific to range requests. If-Range is defined in <a href="p5-range.html#header.if-range" title="If-Range">Section 3.2</a> of <a href="#Part5" id="rfc.xref.Part5.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>.
     1067      <p id="rfc.section.3.5.p.1">The "If-Range" header field provides a special conditional request mechanism that is similar the <a href="#header.if-match" class="smpl">If-Match</a> and <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> fields but instructs the recipient to ignore the <a href="p5-range.html#header.range" class="smpl">Range</a> header field if the validator doesn't match, resulting in transfer of the new selected representation instead of a 412 response.
     1068         If-Range is defined in <a href="p5-range.html#header.if-range" title="If-Range">Section 3.2</a> of <a href="#Part5" id="rfc.xref.Part5.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>.
    10681069      </p>
    10691070      <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="status.code.definitions" href="#status.code.definitions">Status Code Definitions</a></h1>
    … …  
    10811082         cache updates (e.g., <a href="#header.last-modified" class="smpl">Last-Modified</a> might be useful if the response does not have an <a href="#header.etag" class="smpl">ETag</a> field).
    10821083      </p>
    1083       <p id="rfc.section.4.1.p.4">Requirements on a cache that receives a 304 response are defined in <a href="p6-cache.html#freshening.responses" title="Freshening Stored Responses upon Validation">Section 4.2.1</a> of <a href="#Part6" id="rfc.xref.Part6.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>. If the conditional request originated with an outbound client, such as a user agent with its own cache sending a conditional
     1084      <p id="rfc.section.4.1.p.4">Requirements on a cache that receives a 304 response are defined in <a href="p6-cache.html#freshening.responses" title="Freshening Stored Responses upon Validation">Section 4.2.1</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>. If the conditional request originated with an outbound client, such as a user agent with its own cache sending a conditional
    10841085         GET to a shared proxy, then the proxy <em class="bcp14">SHOULD</em> forward the 304 response to that client.
    10851086      </p>
    … …  
    10871088      <div id="rfc.iref.21"></div>
    10881089      <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a id="status.412" href="#status.412">412 Precondition Failed</a></h2>
    1089       <p id="rfc.section.4.2.p.1">The <dfn>412 (Precondition Failed)</dfn> status code indicates that one or more preconditions given in the request header fields evaluated to false when tested on
    1090          the server. This response code allows the client to place preconditions on the current resource state (its current representations
     1090      <p id="rfc.section.4.2.p.1">The <dfn>412 (Precondition Failed)</dfn> status code indicates that one or more conditions given in the request header fields evaluated to false when tested on the
     1091         server. This response code allows the client to place preconditions on the current resource state (its current representations
    10911092         and metadata) and thus prevent the request method from being applied if the target resource is in an unexpected state.
    10921093      </p>
    1093       <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="precedence" href="#precedence">Evaluation and Precedence</a></h1>
    1094       <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
    1095          perform the action associated with the request method). Preconditions are ignored if the server determines that an error or
    1096          redirect response applies before they are evaluated. Otherwise, the evaluation depends on both the method semantics and the
    1097          choice of conditional.
    1098       </p>
    1099       <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
    1100          held by the client. Evaluating to false is thus an indication that the client can continue to use its local copy of the selected
    1101          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.
    1102       </p>
    1103       <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
    1104          on the target resource if the resource state does not match the expected state. In other words, evaluating the condition to
    1105          false means that the resource has been changed by some other client, perhaps by another user attempting to edit the same resource,
    1106          and thus preventing the request from being applied saves the client from overwriting some other client's work. This result
    1107          is indicated by the server generating a <a href="#status.412" class="smpl">412 (Precondition Failed)</a> response.
    1108       </p>
    1109       <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
    1110          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
    1111          on the state of the target resource in general, or on a group of resources. For instance, the If header field in WebDAV can
    1112          make a request conditional on various aspects (such as locks) of multiple resources (<a href="#RFC4918" id="rfc.xref.RFC4918.2"><cite title="HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)">[RFC4918]</cite></a>, <a href="http://tools.ietf.org/html/rfc4918#section-10.4">Section 10.4</a>).
    1113       </p>
    1114       <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
    1115          important. In practice, the fields defined in this document are consistently implemented in a single, logical order, due to
    1116          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.
    1117       </p>
    1118       <p id="rfc.section.5.p.6">The general rule of conditional precedence is that exact match conditions are evaluated before cache-validating conditions
    1119          and, within that order, last-modified conditions are only evaluated if the corresponding entity tag condition is not present
    1120          (or not applicable because the selected representation does not have an entity tag).
    1121       </p>
    1122       <p id="rfc.section.5.p.7">Specifically, the fields defined by this specification are evaluated as follows: </p>
     1094      <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="evaluation" href="#evaluation">Evaluation</a></h1>
     1095      <p id="rfc.section.5.p.1">Except when excluded below, a server <em class="bcp14">MUST</em> evaluate received request preconditions after it has successfully performed its normal request checks and just before it would
     1096         perform the action associated with the request method. A server <em class="bcp14">MUST</em> ignore all received preconditions if its response to the same request without those conditions would have been a status code
     1097         other than a <a href="p2-semantics.html#status.2xx" class="smpl">2xx</a> or <a href="#status.412" class="smpl">412 (Precondition Failed)</a>. In other words, redirects and failures take precedence over the evaluation of preconditions in conditional requests.
     1098      </p>
     1099      <p id="rfc.section.5.p.2">A server that is not the origin server for the target resource and cannot act as a cache for requests on the target resource <em class="bcp14">MUST NOT</em> evaluate the conditional request header fields defined by this specification, and <em class="bcp14">MUST</em> forward them if the request is forwarded, since the generating client intends that they be evaluated by a server that can
     1100         provide a current representation. Likewise, a server <em class="bcp14">MUST</em> ignore the conditional request header fields defined by this specification when received with a request method that does not
     1101         involve the selection or modification of a <a href="p2-semantics.html#representations" class="smpl">selected representation</a>, such as CONNECT, OPTIONS, or TRACE.
     1102      </p>
     1103      <p id="rfc.section.5.p.3">Conditional request header fields that are defined by extensions to HTTP might place conditions on all recipients, on the
     1104         state of the target resource in general, or on a group of resources. For instance, the "If" header field in WebDAV can make
     1105         a request conditional on various aspects of multiple resources, such as locks, if the recipient understands and implements
     1106         that field (<a href="#RFC4918" id="rfc.xref.RFC4918.2"><cite title="HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)">[RFC4918]</cite></a>, <a href="http://tools.ietf.org/html/rfc4918#section-10.4">Section 10.4</a>).
     1107      </p>
     1108      <p id="rfc.section.5.p.4">Although conditional request header fields are defined as being usable with the HEAD method (to keep HEAD's semantics consistent
     1109         with those of GET), there is no point in sending a conditional HEAD because a successful response is around the same size
     1110         as a <a href="#status.304" class="smpl">304 (Not Modified)</a> response and more useful than a <a href="#status.412" class="smpl">412 (Precondition Failed)</a> response.
     1111      </p>
     1112      <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="precedence" href="#precedence">Precedence</a></h1>
     1113      <p id="rfc.section.6.p.1">When more than one conditional request header field is present in a request, the order in which the fields are evaluated becomes
     1114         important. In practice, the fields defined in this document are consistently implemented in a single, logical order, since
     1115         "lost update" preconditions have more strict requirements than cache validation, a validated cache is more efficient than
     1116         a partial response, and entity tags are presumed to be more accurate than date validators.
     1117      </p>
     1118      <p id="rfc.section.6.p.2">A recipient cache or origin server <em class="bcp14">MUST</em> evaluate the request preconditions defined by this specification in the following order:
     1119      </p>
    11231120      <ol>
    11241121         <li id="precedence1">When <a href="#header.if-match" class="smpl">If-Match</a> is present, evaluate it:
    … …  
    11601157         </li>
    11611158      </ol>
    1162       <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
     1159      <p id="rfc.section.6.p.3">Any extension to HTTP/1.1 that defines additional conditional request header fields ought to define its own expectations regarding
    11631160         the order for evaluating such fields in relation to those defined in this document and other conditionals that might be found
    11641161         in practice.
    11651162      </p>
    1166       <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>
    1167       <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a>&nbsp;<a id="status.code.registration" href="#status.code.registration">Status Code Registration</a></h2>
    1168       <p id="rfc.section.6.1.p.1">The HTTP Status Code Registry located at &lt;<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>&gt; shall be updated with the registrations below:
     1163      <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>
     1164      <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a>&nbsp;<a id="status.code.registration" href="#status.code.registration">Status Code Registration</a></h2>
     1165      <p id="rfc.section.7.1.p.1">The HTTP Status Code Registry located at &lt;<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>&gt; shall be updated with the registrations below:
    11691166      </p>
    11701167      <div id="rfc.table.1">
    … …  
    11941191         </table>
    11951192      </div>
    1196       <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a>&nbsp;<a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2>
    1197       <p id="rfc.section.6.2.p.1">HTTP header fields are registered within the Message Header Field Registry maintained at &lt;<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>&gt;.
    1198       </p>
    1199       <p id="rfc.section.6.2.p.2">This document defines the following HTTP header fields, so their associated registry entries shall be updated according to
     1193      <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a>&nbsp;<a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2>
     1194      <p id="rfc.section.7.2.p.1">HTTP header fields are registered within the Message Header Field Registry maintained at &lt;<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>&gt;.
     1195      </p>
     1196      <p id="rfc.section.7.2.p.2">This document defines the following HTTP header fields, so their associated registry entries shall be updated according to
    12001197         the permanent registrations below (see <a href="#BCP90" id="rfc.xref.BCP90.1"><cite title="Registration Procedures for Message Header Fields">[BCP90]</cite></a>):
    12011198      </p>
    … …  
    12571254         </table>
    12581255      </div>
    1259       <p id="rfc.section.6.2.p.3">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p>
    1260       <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a id="security.considerations" href="#security.considerations">Security Considerations</a></h1>
    1261       <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
     1256      <p id="rfc.section.7.2.p.3">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p>
     1257      <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a>&nbsp;<a id="security.considerations" href="#security.considerations">Security Considerations</a></h1>
     1258      <p id="rfc.section.8.p.1">This section is meant to inform developers, information providers, and users of known security concerns specific to the HTTP/1.1
    12621259         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.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>.
    12631260      </p>
    1264       <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
     1261      <p id="rfc.section.8.p.2">The validators defined by this specification are not intended to ensure the validity of a representation, guard against malicious
    12651262         changes, or detect man-in-the-middle attacks. At best, they enable more efficient cache updates and optimistic concurrent
    12661263         writes when all participants are behaving nicely. At worst, the conditions will fail and the client will receive a response
    12671264         that is no more harmful than an HTTP exchange without conditional requests.
    12681265      </p>
    1269       <p id="rfc.section.7.p.3">An entity-tag can be abused in ways that create privacy risks. For example, a site might deliberately construct a semantically
     1266      <p id="rfc.section.8.p.3">An entity-tag can be abused in ways that create privacy risks. For example, a site might deliberately construct a semantically
    12701267         invalid entity-tag that is unique to the user or user agent, send it in a cacheable response with a long freshness time, and
    12711268         then read that entity-tag in later conditional requests as a means of re-identifying that user or user agent. Such an identifying
    … …  
    12741271         actions, such as clearing stored cookies or changing to a private browsing mode.
    12751272      </p>
    1276       <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a>&nbsp;<a id="acks" href="#acks">Acknowledgments</a></h1>
    1277       <p id="rfc.section.8.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 10</a> of <a href="#Part1" id="rfc.xref.Part1.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.
    1278       </p>
    1279       <h1 id="rfc.references"><a id="rfc.section.9" href="#rfc.section.9">9.</a> References
     1273      <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;<a id="acks" href="#acks">Acknowledgments</a></h1>
     1274      <p id="rfc.section.9.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 10</a> of <a href="#Part1" id="rfc.xref.Part1.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.
     1275      </p>
     1276      <h1 id="rfc.references"><a id="rfc.section.10" href="#rfc.section.10">10.</a> References
    12801277      </h1>
    1281       <h2 id="rfc.references.1"><a href="#rfc.section.9.1" id="rfc.section.9.1">9.1</a> Normative References
     1278      <h2 id="rfc.references.1"><a href="#rfc.section.10.1" id="rfc.section.10.1">10.1</a> Normative References
    12821279      </h2>
    12831280      <table>
    … …  
    13131310         </tr>
    13141311      </table>
    1315       <h2 id="rfc.references.2"><a href="#rfc.section.9.2" id="rfc.section.9.2">9.2</a> Informative References
     1312      <h2 id="rfc.references.2"><a href="#rfc.section.10.2" id="rfc.section.10.2">10.2</a> Informative References
    13161313      </h2>
    13171314      <table>
    … …  
    13511348         situations (such as a PUT response). (<a href="#header.etag" id="rfc.xref.header.etag.4" title="ETag">Section&nbsp;2.3</a>)
    13521349      </p>
    1353       <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>)
     1350      <p id="rfc.section.A.p.5">The precedence for evaluation of conditional requests has been defined. (<a href="#precedence" title="Precedence">Section&nbsp;6</a>)
    13541351      </p>
    13551352      <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="imported.abnf" href="#imported.abnf">Imported ABNF</a></h1>
    … …  
    14631460         <ul class="ind">
    14641461            <li><a id="rfc.index.3" href="#rfc.index.3"><b>3</b></a><ul>
    1465                   <li>304 Not Modified (status code)&nbsp;&nbsp;<a href="#rfc.iref.21"><b>4.1</b></a>, <a href="#rfc.xref.status.304.1">6.1</a></li>
     1462                  <li>304 Not Modified (status code)&nbsp;&nbsp;<a href="#rfc.iref.21"><b>4.1</b></a>, <a href="#rfc.xref.status.304.1">7.1</a></li>
    14661463               </ul>
    14671464            </li>
    14681465            <li><a id="rfc.index.4" href="#rfc.index.4"><b>4</b></a><ul>
    1469                   <li>412 Precondition Failed (status code)&nbsp;&nbsp;<a href="#rfc.iref.21"><b>4.2</b></a>, <a href="#rfc.xref.status.412.1">6.1</a></li>
     1466                  <li>412 Precondition Failed (status code)&nbsp;&nbsp;<a href="#rfc.iref.21"><b>4.2</b></a>, <a href="#rfc.xref.status.412.1">7.1</a></li>
    14701467               </ul>
    14711468            </li>
    14721469            <li><a id="rfc.index.B" href="#rfc.index.B"><b>B</b></a><ul>
    1473                   <li><em>BCP90</em>&nbsp;&nbsp;<a href="#rfc.xref.BCP90.1">6.2</a>, <a href="#BCP90"><b>9.2</b></a></li>
     1470                  <li><em>BCP90</em>&nbsp;&nbsp;<a href="#rfc.xref.BCP90.1">7.2</a>, <a href="#BCP90"><b>10.2</b></a></li>
    14741471               </ul>
    14751472            </li>
    14761473            <li><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul>
    1477                   <li>ETag header field&nbsp;&nbsp;<a href="#rfc.xref.header.etag.1">2</a>, <a href="#rfc.iref.e.1"><b>2.3</b></a>, <a href="#rfc.xref.header.etag.2">6.2</a>, <a href="#rfc.xref.header.etag.3">A</a>, <a href="#rfc.xref.header.etag.4">A</a></li>
     1474                  <li>ETag header field&nbsp;&nbsp;<a href="#rfc.xref.header.etag.1">2</a>, <a href="#rfc.iref.e.1"><b>2.3</b></a>, <a href="#rfc.xref.header.etag.2">7.2</a>, <a href="#rfc.xref.header.etag.3">A</a>, <a href="#rfc.xref.header.etag.4">A</a></li>
    14781475               </ul>
    14791476            </li>
    … …  
    14961493            </li>
    14971494            <li><a id="rfc.index.I" href="#rfc.index.I"><b>I</b></a><ul>
    1498                   <li>If-Match header field&nbsp;&nbsp;<a href="#rfc.iref.i.1"><b>3.1</b></a>, <a href="#rfc.xref.header.if-match.1">5</a>, <a href="#rfc.xref.header.if-match.2">6.2</a></li>
    1499                   <li>If-Modified-Since header field&nbsp;&nbsp;<a href="#rfc.iref.i.3"><b>3.3</b></a>, <a href="#rfc.xref.header.if-modified-since.1">6.2</a></li>
    1500                   <li>If-None-Match header field&nbsp;&nbsp;<a href="#rfc.iref.i.2"><b>3.2</b></a>, <a href="#rfc.xref.header.if-none-match.1">6.2</a>, <a href="#rfc.xref.header.if-none-match.2">A</a></li>
    1501                   <li>If-Unmodified-Since header field&nbsp;&nbsp;<a href="#rfc.iref.i.4"><b>3.4</b></a>, <a href="#rfc.xref.header.if-unmodified-since.1">5</a>, <a href="#rfc.xref.header.if-unmodified-since.2">6.2</a></li>
     1495                  <li>If-Match header field&nbsp;&nbsp;<a href="#rfc.iref.i.1"><b>3.1</b></a>, <a href="#rfc.xref.header.if-match.1">6</a>, <a href="#rfc.xref.header.if-match.2">7.2</a></li>
     1496                  <li>If-Modified-Since header field&nbsp;&nbsp;<a href="#rfc.iref.i.3"><b>3.3</b></a>, <a href="#rfc.xref.header.if-modified-since.1">7.2</a></li>
     1497                  <li>If-None-Match header field&nbsp;&nbsp;<a href="#rfc.iref.i.2"><b>3.2</b></a>, <a href="#rfc.xref.header.if-none-match.1">7.2</a>, <a href="#rfc.xref.header.if-none-match.2">A</a></li>
     1498                  <li>If-Unmodified-Since header field&nbsp;&nbsp;<a href="#rfc.iref.i.4"><b>3.4</b></a>, <a href="#rfc.xref.header.if-unmodified-since.1">6</a>, <a href="#rfc.xref.header.if-unmodified-since.2">7.2</a></li>
    15021499               </ul>
    15031500            </li>
    15041501            <li><a id="rfc.index.L" href="#rfc.index.L"><b>L</b></a><ul>
    1505                   <li>Last-Modified header field&nbsp;&nbsp;<a href="#rfc.xref.header.last-modified.1">2</a>, <a href="#rfc.iref.l.1"><b>2.2</b></a>, <a href="#rfc.xref.header.last-modified.2">6.2</a></li>
     1502                  <li>Last-Modified header field&nbsp;&nbsp;<a href="#rfc.xref.header.last-modified.1">2</a>, <a href="#rfc.iref.l.1"><b>2.2</b></a>, <a href="#rfc.xref.header.last-modified.2">7.2</a></li>
    15061503               </ul>
    15071504            </li>
    … …  
    15111508            </li>
    15121509            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    1513                   <li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.1</a>, <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.4">2.3.3</a>, <a href="#rfc.xref.Part1.5">7</a>, <a href="#rfc.xref.Part1.6">8</a>, <a href="#Part1"><b>9.1</b></a>, <a href="#rfc.xref.Part1.7">B</a>, <a href="#rfc.xref.Part1.8">B</a>, <a href="#rfc.xref.Part1.9">B</a>, <a href="#rfc.xref.Part1.10">C</a><ul>
     1510                  <li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.1</a>, <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.4">2.3.3</a>, <a href="#rfc.xref.Part1.5">8</a>, <a href="#rfc.xref.Part1.6">9</a>, <a href="#Part1"><b>10.1</b></a>, <a href="#rfc.xref.Part1.7">B</a>, <a href="#rfc.xref.Part1.8">B</a>, <a href="#rfc.xref.Part1.9">B</a>, <a href="#rfc.xref.Part1.10">C</a><ul>
    15141511                        <li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.10">C</a></li>
    15151512                        <li><em>Section 2.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.2">1.1</a></li>
    … …  
    15181515                        <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.4">2.3.3</a></li>
    15191516                        <li><em>Section 7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.3">1.2</a></li>
    1520                         <li><em>Section 10</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.6">8</a></li>
     1517                        <li><em>Section 10</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.6">9</a></li>
    15211518                     </ul>
    15221519                  </li>
    1523                   <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">3.2</a>, <a href="#rfc.xref.Part2.6">7</a>, <a href="#Part2"><b>9.1</b></a>, <a href="#rfc.xref.Part2.7">B</a><ul>
     1520                  <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">3.2</a>, <a href="#rfc.xref.Part2.6">8</a>, <a href="#Part2"><b>10.1</b></a>, <a href="#rfc.xref.Part2.7">B</a><ul>
    15241521                        <li><em>Section 3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">1</a></li>
    15251522                        <li><em>Section 3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">2.3.3</a></li>
    … …  
    15291526                     </ul>
    15301527                  </li>
    1531                   <li><em>Part5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.1">3.5</a>, <a href="#rfc.xref.Part5.2">5</a>, <a href="#Part5"><b>9.1</b></a><ul>
     1528                  <li><em>Part5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.1">3.5</a>, <a href="#rfc.xref.Part5.2">6</a>, <a href="#Part5"><b>10.1</b></a><ul>
    15321529                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.1">3.5</a></li>
    15331530                     </ul>
    15341531                  </li>
    1535                   <li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">1</a>, <a href="#rfc.xref.Part6.2">2.2.1</a>, <a href="#rfc.xref.Part6.3">2.3.1</a>, <a href="#rfc.xref.Part6.4">3.1</a>, <a href="#rfc.xref.Part6.5">3.4</a>, <a href="#rfc.xref.Part6.6">4.1</a>, <a href="#Part6"><b>9.1</b></a><ul>
    1536                         <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.4">3.1</a>, <a href="#rfc.xref.Part6.5">3.4</a></li>
    1537                         <li><em>Section 4.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.6">4.1</a></li>
     1532                  <li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">1</a>, <a href="#rfc.xref.Part6.2">2.2.1</a>, <a href="#rfc.xref.Part6.3">2.3.1</a>, <a href="#rfc.xref.Part6.4">3.1</a>, <a href="#rfc.xref.Part6.5">3.2</a>, <a href="#rfc.xref.Part6.6">3.3</a>, <a href="#rfc.xref.Part6.7">3.4</a>, <a href="#rfc.xref.Part6.8">4.1</a>, <a href="#Part6"><b>10.1</b></a><ul>
     1533                        <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.4">3.1</a>, <a href="#rfc.xref.Part6.5">3.2</a>, <a href="#rfc.xref.Part6.6">3.3</a>, <a href="#rfc.xref.Part6.7">3.4</a></li>
     1534                        <li><em>Section 4.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.8">4.1</a></li>
    15381535                     </ul>
    15391536                  </li>
    … …  
    15411538            </li>
    15421539            <li><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul>
    1543                   <li><em>RFC2119</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>9.1</b></a></li>
    1544                   <li><em>RFC2616</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">2.3</a>, <a href="#RFC2616"><b>9.2</b></a><ul>
     1540                  <li><em>RFC2119</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>10.1</b></a></li>
     1541                  <li><em>RFC2616</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">2.3</a>, <a href="#RFC2616"><b>10.2</b></a><ul>
    15451542                        <li><em>Section 3.11</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">2.3</a></li>
    15461543                     </ul>
    15471544                  </li>
    1548                   <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><ul>
     1545                  <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>10.2</b></a><ul>
    15491546                        <li><em>Section 10.4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4918.2">5</a></li>
    15501547                     </ul>
    15511548                  </li>
    1552                   <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>
     1549                  <li><em>RFC5234</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5234.1">1.2</a>, <a href="#RFC5234"><b>10.1</b></a>, <a href="#rfc.xref.RFC5234.2">B</a><ul>
    15531550                        <li><em>Appendix B.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5234.2">B</a></li>
    15541551                     </ul>

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

    r2358 r2361  
    151151</t>
    152152<t>
    153    The conditional request preconditions defined by this specification are
    154    evaluated by comparing the validators provided in the conditional request
    155    header fields to the current validators for the selected representation
    156    in the order defined by <xref target="precedence"/>.
     153   The conditional request preconditions defined by this specification
     154   (<xref target="preconditions"/>) are evaluated when applicable to the
     155   recipient (<xref target="evaluation"/>) according to their order of
     156   precedence (<xref target="precedence"/>).
    157157</t>
    158158
    … …  
    650650</section>
    651651
    652 <section title="Precondition Header Fields" anchor="header.field.definitions">
     652<section title="Precondition Header Fields" anchor="preconditions">
    653653<t>
    654654   This section defines the syntax and semantics of HTTP/1.1 header fields
    655655   for applying preconditions on requests.
    656    <xref target="precedence"/> defines when the preconditions are applied and
    657    the order of evaluation when more than one precondition is present.
     656   <xref target="evaluation"/> defines when the preconditions are applied.
     657   <xref target="precedence"/> defines the order of evaluation when more than
     658   one precondition is present.
    658659</t>
    659660
    … …  
    662663  <x:anchor-alias value="If-Match"/>
    663664<t>
    664    The "If-Match" header field makes the request method conditional on either
    665    the existence of a current representation for the target resource, when
    666    the field-value is "*", or on the selected representation having an
    667    entity-tag that matches one of those provided in the field-value.
     665   The "If-Match" header field makes the request method conditional on the
     666   recipient cache or origin server either having at least one current
     667   representation of the target resource, when the field-value is "*", or
     668   having a current representation of the target resource that has an
     669   entity-tag matching a member of the list of entity-tags provided in the
     670   field-value.
     671   A recipient &MUST; use the strong comparison function when comparing
     672   entity-tags for If-Match (<xref target="entity.tag.comparison"/>).
    668673</t>
    669674<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-Match"/>
    … …  
    679684</artwork></figure>
    680685<t>
    681    If the request semantics (method and header fields) allow the request to be
    682    satisfied with a cached response, a cache &SHOULD; evaluate the condition
    683    based on its currently stored set of suitable responses for that request
    684    (see &cache-key;).
    685    If the field-value is "*" and any suitable response is currently stored,
    686    or if the field-value is a list of entity-tag values and at least one of
    687    the suitable responses has an <x:ref>ETag</x:ref> header field with a
    688    value matching an entity-tag in that list, then the cache &SHOULD; reuse
    689    the most suitable of those matching responses to satisfy the request.
    690    If the condition is not met, none of the cached responses is suitable for
    691    reuse in response to this request.
    692 </t>
    693 <t>
    694    If the request semantics cannot be satisfied with a cached response, the
    695    conditional is only evaluated when received by an origin server.
    696    For example, If-Match is most often used with state-changing requests,
    697    such as PUT, to prevent accidental overwrites when multiple user agents
    698    might be acting in parallel on the same resource (i.e., to prevent the
    699    "lost update" problem).
    700 </t>
    701 <t>
    702    When the If-Match field-value consists of a list of entity-tag values,
    703    the condition is met if any of the entity-tags listed match, using the weak
    704    comparison function (as per <xref target="entity.tag.comparison"/>), the
    705    entity-tag of the selected representation.
    706    When the If-Match field-value is "*", the condition is met if any current
    707    representation exists for the target resource.
    708 </t>
    709 <t>
    710    If the condition is met, the origin server &MAY; perform the requested
    711    method.
    712 </t>
    713 <t>
    714    An origin server &MUST-NOT; perform the requested method if the condition
    715    is not met; instead the origin server &MUST; respond with either:
     686   If-Match is most often used with state-changing methods (e.g., POST, PUT,
     687   DELETE) to prevent accidental overwrites when multiple user agents might be
     688   acting in parallel on the same resource (i.e., to prevent the "lost update"
     689   problem). It can also be used with safe methods to abort a request if the
     690   <x:ref>selected representation</x:ref> does not match one already stored
     691   (or partially stored) from a prior request.
     692</t>
     693<t>
     694   An origin server that receives an If-Match header field &MUST; evaluate the
     695   condition prior to performing the method (<xref target="evaluation"/>).
     696   If the field-value is "*", the condition is false if the origin server
     697   does not have a current representation for the target resource.
     698   If the field-value is a list of entity-tags, the condition is false if
     699   none of the listed tags match the entity-tag of the selected representation.
     700</t>
     701<t>
     702   An origin server &MUST-NOT; perform the requested method if a received
     703   If-Match condition evaluates to false; instead the origin server &MUST;
     704   respond with either:
    716705   a) the <x:ref>412 (Precondition Failed)</x:ref> status code; or,
    717706   b) one of the <x:ref>2xx (Successful)</x:ref> status codes if the origin
    … …  
    719708   state is already reflected in the current state of the target resource
    720709   (i.e., the change requested by the user agent has already succeeded, but
    721    the user agent might not be aware of that because the prior response message
     710   the user agent might not be aware of it, perhaps because the prior response
    722711   was lost or a compatible change was made by some other user agent).
    723712   In the latter case, the origin server &MUST-NOT; send a validator header
    … …  
    725714   of an immediately prior change made by the same user agent.
    726715</t>
     716<t>
     717   If the request semantics can be satisfied with a cached response, a
     718   recipient cache &MUST; evaluate the condition as part of its selection
     719   process for determining a suitable response for that primary cache key
     720   (see &cache-key;).
     721   The cache &MUST; generate a <x:ref>412 (Precondition Failed)</x:ref>
     722   response if the field-value is "*" and no suitable response is stored, or
     723   if the field-value is a list of entity-tags and none of them match the
     724   entity-tag of a suitable stored response.
     725   Otherwise, the cache &MUST; generate a successful <x:ref>2xx</x:ref>
     726   response that reuses the most recent of its matching stored responses to
     727   satisfy the request.
     728</t>
    727729</section>
    728730
    … …  
    731733  <x:anchor-alias value="If-None-Match"/>
    732734<t>
    733    The "If-None-Match" header field can be used to make a request method
    734    conditional on not matching any of the current entity-tag values for
    735    representations of the target resource.
    736 </t>
     735   The "If-None-Match" header field makes the request method conditional on
     736   the recipient cache or origin server either not having a current
     737   representation for the target resource, when the field-value is "*", or
     738   not having a current representation that has an entity-tag matching a
     739   member of the list of entity-tags provided in the field-value.
     740   A recipient &MUST; use the weak comparison function when comparing
     741   entity-tags for If-None-Match (<xref target="entity.tag.comparison"/>).
     742</t>
     743<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-None-Match"/>
     744  <x:ref>If-None-Match</x:ref> = "*" / 1#<x:ref>entity-tag</x:ref>
     745</artwork></figure>
     746<t>
     747   Examples:
     748</t>
     749<figure><artwork type="example">
     750  If-None-Match: "xyzzy"
     751  If-None-Match: W/"xyzzy"
     752  If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
     753  If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
     754  If-None-Match: *
     755</artwork></figure>
    737756<t>
    738757   If-None-Match is primarily used in conditional GET requests to enable
    739    efficient updates of cached information with a minimum amount of transaction
    740    overhead. A client that has one or more representations previously obtained
    741    from the target resource can send If-None-Match with a list of the
    742    associated entity-tags in the hope of receiving a <x:ref>304 (Not
    743    Modified)</x:ref> response if at least one of those representations matches
    744    the selected representation.
     758   efficient updates of cached information with a minimum amount of
     759   transaction overhead. When a client desires to update one or more stored
     760   responses that have entity-tags, the client &SHOULD; generate an
     761   If-None-Match header field containing a list of those entity-tags when
     762   making a GET request; this allows recipient servers to send a
     763   <x:ref>304 (Not Modified)</x:ref> response to indicate when one of those
     764   stored responses matches the selected representation.
    745765</t>
    746766<t>
    … …  
    753773   resource.
    754774</t>
    755 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-None-Match"/>
    756   <x:ref>If-None-Match</x:ref> = "*" / 1#<x:ref>entity-tag</x:ref>
    757 </artwork></figure>
    758 <t>
    759    The If-None-Match condition is met if and only if none of the entity-tags
    760    listed in the If-None-Match field value match the entity-tag of the selected
    761    representation using the weak comparison function (as per <xref
    762    target="entity.tag.comparison"/>), or if "*" is given and no current
    763    representation exists for that resource.
    764 </t>
    765 <t>
    766    If the condition is not met, the server &MUST-NOT; perform the requested
    767    method. Instead, if the request method was GET or HEAD, the server &SHOULD;
    768    respond with a <x:ref>304 (Not Modified)</x:ref> status code, including the
    769    cache-related header fields (particularly <x:ref>ETag</x:ref>) of the
    770    selected representation that has a matching entity-tag. For all other
    771    request methods, the server &MUST; respond with a <x:ref>412 (Precondition
    772    Failed)</x:ref> status code when the condition is not met.
    773 </t>
    774 <t>
    775    If the condition is met, the server &MAY; perform the requested method and
    776    &MUST; ignore any <x:ref>If-Modified-Since</x:ref> header field(s) in the
    777    request. That is, if no entity-tags match, then the server &MUST-NOT; send
    778    a <x:ref>304 (Not Modified)</x:ref> response.
    779 </t>
    780 <t>
    781    Examples:
    782 </t>
    783 <figure><artwork type="example">
    784   If-None-Match: "xyzzy"
    785   If-None-Match: W/"xyzzy"
    786   If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
    787   If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
    788   If-None-Match: *
    789 </artwork></figure>
     775<t>
     776   An origin server that receives an If-None-Match header field &MUST;
     777   evaluate the condition prior to performing the method
     778   (<xref target="evaluation"/>).
     779   If the field-value is "*", the condition is false if the origin server
     780   has a current representation for the target resource.
     781   If the field-value is a list of entity-tags, the condition is false if
     782   one of the listed tags match the entity-tag of the selected representation.
     783</t>
     784<t>
     785   An origin server &MUST-NOT; perform the requested method if the condition
     786   evaluates to false; instead, the origin server &MUST; respond with either
     787   a) the <x:ref>304 (Not Modified)</x:ref> status code if the request method
     788   is GET or HEAD; or,
     789   b) the <x:ref>412 (Precondition Failed)</x:ref> status code for all other
     790   request methods.
     791</t>
     792<t>
     793   If the request semantics can be satisfied with a cached response, a
     794   recipient cache &SHOULD; evaluate the condition as part of its selection
     795   process for determining a suitable response for that primary cache key
     796   (see &cache-key;). If the field-value is "*" and a suitable response is
     797   stored, or the field-value is a list of entity-tags and at least one of
     798   them match the entity-tag of a suitable stored response, the cache &SHOULD;
     799   generate a <x:ref>304 (Not Modified)</x:ref> response using the most
     800   suitable of those matching responses as the selected representation.
     801   Otherwise, if the cache has one or more suitable stored responses that
     802   do not match the condition, the cache &SHOULD; generate a successful
     803   <x:ref>2xx</x:ref> response that reuses the most suitable of those stored
     804   responses to satisfy the request. Finally, if the cache has no suitable
     805   stored responses, the cache &SHOULD; forward the conditional request toward
     806   the origin server; if the received condition contains a list of entity-tags
     807   and the cache has its own set of stored responses for that primary cache
     808   key, the cache &SHOULD; take the union of the received set with the set of
     809   entity-tags for its own stored set of responses (fresh or stale) and
     810   generate an <x:ref>If-None-Match</x:ref> header field containing that union
     811   when it forwards the request toward the origin server.
     812</t>
    790813</section>
    791814
    … …  
    796819   The "If-Modified-Since" header field can be used with GET or HEAD to make
    797820   the method conditional by modification date: if the selected representation
    798    has not been modified since the time specified in this field, then
    799    do not perform the request method; instead, respond as detailed below.
     821   has not been modified since the time specified in this field, then respond
     822   with a <x:ref>304 (Not Modified)</x:ref> status code and only send
     823   metadata that might be useful for identifying or updating a cached
     824   representation. Hence, transfer of the selected representation's data is
     825   avoided if that data has not changed.
    800826</t>
    801827<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-Modified-Since"/>
    … …  
    809835</artwork></figure>
    810836<t>
    811    A GET method with an If-Modified-Since header field and no <x:ref>Range</x:ref>
    812    header field requests that the selected representation be transferred only if
    813    it has been modified since the date given by the If-Modified-Since
    814    header field.
    815    The algorithm for determining this includes the following cases:
    816   <list style="numbers">
    817       <t>If the request would normally result in anything other than a
    818          <x:ref>200 (OK)</x:ref> status code, or if the passed If-Modified-Since date is
    819          invalid, the response is exactly the same as for a normal GET.
    820          A date that is later than the server's current time is
    821          invalid.</t>
    822 
    823       <t>If the selected representation has been modified since the
    824          If-Modified-Since date, the response is exactly the same as for
    825          a normal GET.</t>
    826 
    827       <t>If the selected representation has not been modified since a valid
    828          If-Modified-Since date, the server &SHOULD; send a
    829          <x:ref>304 (Not Modified)</x:ref> response.</t>
    830   </list>
    831 </t>
    832 <t>
    833    The two purposes of this feature are to allow efficient updates of cached
    834    information, with a minimum amount of transaction overhead, and to limit
    835    the scope of a web traversal to resources that have recently changed.
     837   A recipient &MUST; ignore If-Modified-Since if the request contains an
     838   <x:ref>If-None-Match</x:ref> header field; the condition in
     839   <x:ref>If-None-Match</x:ref> is considered to be a more accurate
     840   replacement for the condition in If-Modified-Since and the two are only
     841   combined for the sake of interoperating with older intermediaries that
     842   might not implement <x:ref>If-None-Match</x:ref>.
     843</t>
     844<t>
     845   A recipient &MUST; ignore the If-Modified-Since header field if the
     846   received field-value is not a valid HTTP-date, or if the request method
     847   is neither GET nor HEAD.
     848</t>
     849<t>
     850   A recipient &MUST; interpret an If-Modified-Since field-value's timestamp
     851   in terms of the origin server's clock.  A recipient cache that evaluates
     852   this precondition &SHOULD; make its comparisons with
     853   respect to a stored <x:ref>Last-Modified</x:ref> or <x:ref>Date</x:ref>
     854   header field, when available in a prior response from that origin server,
     855   rather than comparing it to a timestamp generated by its own clock.
     856</t>
     857<t>
     858   If-Modified-Since is typically used for two distinct purposes:
     859   1) to allow efficient updates of a cached representation that does not
     860   have an entity-tag; and,
     861   2) to limit the scope of a web traversal to resources that have recently
     862   changed.
    836863</t>
    837864<t>
    … …  
    857884   only those changed during the specified window.
    858885</t>
    859 <x:note>
    860   <t>
    861      &Note; If a client uses an arbitrary date in the If-Modified-Since
    862      header field instead of a date taken from a <x:ref>Last-Modified</x:ref>
    863      or <x:ref>Date</x:ref> header field from the origin server, the client
    864      ought to be aware that its date will be interpreted according to the
    865      server's understanding of time.
    866   </t>
    867 </x:note>
     886<t>
     887   If the request semantics can be satisfied with a cached response, a
     888   recipient cache &SHOULD; evaluate the condition as part of its selection
     889   process for determining a suitable response for that primary cache key
     890   (see &cache-key;).
     891   The cache &SHOULD; forward the conditional request toward the origin server
     892   if it does not have any suitable stored responses.
     893   The cache &SHOULD; generate a successful
     894   <x:ref>2xx</x:ref> response, reusing the most recent of its stored
     895   responses to satisfy the request, if one of the following is true:
     896   1) a stored response has a <x:ref>Last-Modified</x:ref> field-value that
     897   is more recent than the conditional timestamp;
     898   2) no <x:ref>Last-Modified</x:ref> field is present, but a stored
     899   response has a <x:ref>Date</x:ref> field-value that is more recent than the
     900   conditional timestamp; or,
     901   3) neither <x:ref>Last-Modified</x:ref> nor <x:ref>Date</x:ref> is present,
     902   but the cache recorded a stored response as having been received at a
     903   time more recent than the conditional timestamp.
     904   Otherwise, the cache &SHOULD; generate a <x:ref>304 (Not Modified)</x:ref>
     905   response using the most recent of the stored responses as the selected
     906   representation.
     907</t>
    868908</section>
    869909
    … …  
    888928</artwork></figure>
    889929<t>
    890    A server &MUST; ignore If-Unmodified-Since if the selected representation
    891    has an entity-tag and the request contains an If-Match header field;
    892    the condition in If-Match, when applicable, is considered to be a more
    893    accurate replacement for the condition in If-Unmodified-Since.
    894 </t>
    895 <t>
    896    A server &MUST; ignore the If-Unmodified-Since header field if the
     930   A recipient &MUST; ignore If-Unmodified-Since if the request contains an
     931   <x:ref>If-Match</x:ref> header field; the condition in
     932   <x:ref>If-Match</x:ref> is considered to be a more accurate replacement for
     933   the condition in If-Unmodified-Since and the two are only combined for the
     934   sake of interoperating with older intermediaries that might not implement
     935   <x:ref>If-Match</x:ref>.
     936</t>
     937<t>
     938   A recipient &MUST; ignore the If-Unmodified-Since header field if the
    897939   received field-value is not a valid HTTP-date.
    898940</t>
    899941<t>
    900    If the request semantics (method and header fields) allow the request to be
    901    satisfied with a cached response, a cache &SHOULD; evaluate the condition
    902    based on its currently stored set of suitable responses for that request
    903    (see &cache-key;).
    904    If the most suitable response has a <x:ref>Last-Modified</x:ref> date that
    905    is earlier or equal to the date given in If-Unmodified-Since, the
    906    cache &SHOULD; reuse that response to satisfy the request.
    907    If the condition is not met, none of the stored responses is suitable for
    908    reuse in response to this request.
    909 </t>
    910 <t>
    911    If the request semantics cannot be satisfied with a cached response, the
    912    conditional is only evaluated when received by an origin server.
    913    If the selected representation has not been modified since the time
    914    specified in this field, then the condition is met.
    915 </t>
    916 <t>
    917    If the condition is met, the origin server &MAY; perform the requested
    918    method.
    919 </t>
    920 <t>
    921    An origin server &MUST-NOT; perform the requested method if the condition
    922    is not met; instead the origin server &MUST; respond with either:
     942   A recipient &MUST; interpret an If-Unmodified-Since field-value's timestamp
     943   in terms of the origin server's clock.
     944</t>
     945<t>
     946   If-Unmodified-Since is most often used with state-changing methods
     947   (e.g., POST, PUT, DELETE) to prevent accidental overwrites when multiple
     948   user agents might be acting in parallel on a resource that resource does
     949   not supply entity-tags with its representations (i.e., to prevent the
     950   "lost update" problem). It can also be used with safe methods to abort a
     951   request if the <x:ref>selected representation</x:ref> does not match one
     952   already stored (or partially stored) from a prior request.
     953</t>
     954<t>
     955   An origin server that receives an If-Unmodified-Since header field &MUST;
     956   evaluate the condition prior to performing the method
     957   (<xref target="evaluation"/>). The condition is false if the selected
     958   representation has been modified since the time specified in this field.
     959</t>
     960<t>
     961   An origin server &MUST-NOT; perform the requested method if a received
     962   If-Unmodified-Since condition evaluates to false; instead the
     963   origin server &MUST; respond with either:
    923964   a) the <x:ref>412 (Precondition Failed)</x:ref> status code; or,
    924965   b) one of the <x:ref>2xx (Successful)</x:ref> status codes if the origin
    … …  
    932973   of an immediately prior change made by the same user agent.
    933974</t>
     975<t>
     976   If the request semantics can be satisfied with a cached response, a
     977   recipient cache &MUST; evaluate the condition as part of its selection
     978   process for determining a suitable response for that primary cache key
     979   (see &cache-key;).
     980   The cache &MUST; forward the conditional request toward the origin server
     981   if it does not have any suitable stored responses.
     982   The cache &MUST; generate a successful <x:ref>2xx</x:ref> response that
     983   reuses the most recent of its suitable stored responses to satisfy the
     984   request if that stored response has a <x:ref>Last-Modified</x:ref> date
     985   that is equal to or earlier than the date given in If-Unmodified-Since.
     986   Otherwise, the cache &MUST; respond with a
     987   <x:ref>412 (Precondition Failed)</x:ref> status code.
     988</t>
    934989</section>
    935990
    … …  
    937992<t>
    938993   The "If-Range" header field provides a special conditional request
    939    mechanism that is similar to <x:ref>If-Match</x:ref> and
    940    <x:ref>If-Unmodified-Since</x:ref> but specific to range requests.
    941    If-Range is defined in &header-if-range;.
     994   mechanism that is similar the <x:ref>If-Match</x:ref> and
     995   <x:ref>If-Unmodified-Since</x:ref> fields but instructs the recipient to
     996   ignore the <x:ref>Range</x:ref> header field if the validator doesn't
     997   match, resulting in transfer of the new selected representation instead of
     998   a 412 response. If-Range is defined in &header-if-range;.
    942999</t>
    9431000</section>
    … …  
    9981055<t>
    9991056   The <x:dfn>412 (Precondition Failed)</x:dfn> status code indicates that one
    1000    or more preconditions given in the request header fields evaluated to false
     1057   or more conditions given in the request header fields evaluated to false
    10011058   when tested on the server. This response code allows the client to place
    10021059   preconditions on the current resource state (its current representations
    … …  
    10071064</section>
    10081065
    1009 <section title="Evaluation and Precedence" anchor="precedence">
    1010 <t>
    1011    For each conditional request, a server &MUST; evaluate the request
     1066<section title="Evaluation" anchor="evaluation">
     1067<t>
     1068   Except when excluded below, a server &MUST; evaluate received request
    10121069   preconditions after it has successfully performed its normal request checks
    1013    (i.e., just before it would perform the action associated with the request
    1014    method). Preconditions are ignored if the server determines that an error
    1015    or redirect response applies before they are evaluated. Otherwise, the
    1016    evaluation depends on both the method semantics and the choice of
    1017    conditional.
    1018 </t>
    1019 <t>
    1020    A conditional request header field that is designed specifically for cache
    1021    validation, which includes <x:ref>If-None-Match</x:ref> and
    1022    <x:ref>If-Modified-Since</x:ref> when used in a GET or HEAD request,
    1023    allows cached representations to be refreshed without repeatedly
    1024    transferring data already held by the client. Evaluating to false is thus
    1025    an indication that the client can continue to use its local copy of the
    1026    selected representation, as indicated by the server generating a
    1027    <x:ref>304 (Not Modified)</x:ref> response that includes only those header
    1028    fields useful for refreshing the cached representation.
    1029 </t>
    1030 <t>
    1031    All other conditionals are intended to signal failure when the
    1032    precondition evaluates to false. For example, an <x:ref>If-Match</x:ref>
    1033    conditional sent with a state-changing method (e.g., POST, PUT, DELETE) is
    1034    intended to prevent the request from taking effect on the target resource
    1035    if the resource state does not match the expected state. In other words,
    1036    evaluating the condition to false means that the resource has been changed
    1037    by some other client, perhaps by another user attempting to edit the same
    1038    resource, and thus preventing the request from being applied saves the
    1039    client from overwriting some other client's work. This result is indicated
    1040    by the server generating a <x:ref>412 (Precondition Failed)</x:ref>
     1070   and just before it would perform the action associated with the request
     1071   method.
     1072   A server &MUST; ignore all received preconditions if its response to the
     1073   same request without those conditions would have been a status code other
     1074   than a <x:ref>2xx</x:ref> or <x:ref>412 (Precondition Failed)</x:ref>.
     1075   In other words, redirects and failures take precedence over the evaluation
     1076   of preconditions in conditional requests.
     1077</t>
     1078<t>
     1079   A server that is not the origin server for the target resource and cannot
     1080   act as a cache for requests on the target resource &MUST-NOT; evaluate the
     1081   conditional request header fields defined by this specification, and
     1082   &MUST; forward them if the request is forwarded, since the generating
     1083   client intends that they be evaluated by a server that can provide a
     1084   current representation.
     1085   Likewise, a server &MUST; ignore the conditional request header fields
     1086   defined by this specification when received with a request method that does
     1087   not involve the selection or modification of a
     1088   <x:ref>selected representation</x:ref>, such as CONNECT, OPTIONS, or TRACE.
     1089</t>
     1090<t>
     1091   Conditional request header fields that are defined by extensions to HTTP
     1092   might place conditions on all recipients, on the state of the target
     1093   resource in general, or on a group of resources. For instance, the "If"
     1094   header field in WebDAV can make a request conditional on various aspects
     1095   of multiple resources, such as locks, if the recipient understands and
     1096   implements that field (<xref target="RFC4918" x:fmt="," x:sec="10.4"/>).
     1097</t>
     1098<t>
     1099   Although conditional request header fields are defined as being usable with
     1100   the HEAD method (to keep HEAD's semantics consistent with those of GET),
     1101   there is no point in sending a conditional HEAD because a successful
     1102   response is around the same size as a <x:ref>304 (Not Modified)</x:ref>
     1103   response and more useful than a <x:ref>412 (Precondition Failed)</x:ref>
    10411104   response.
    10421105</t>
    1043 <t>
    1044    The conditional request header fields defined by this specification are
    1045    ignored for request methods that never involve the selection or
    1046    modification of a <x:ref>selected representation</x:ref> (e.g., CONNECT,
    1047    OPTIONS, and TRACE). Other conditional request header fields, defined by
    1048    extensions to HTTP, might place conditions on the state of the target
    1049    resource in general, or on a group of resources. For instance, the If header
    1050    field in WebDAV can make a request conditional on various aspects (such
    1051    as locks) of multiple resources
    1052    (<xref target="RFC4918" x:fmt="," x:sec="10.4"/>).
    1053 </t>
     1106</section>
     1107
     1108<section title="Precedence" anchor="precedence">
    10541109<t>
    10551110   When more than one conditional request header field is present in a request,
    10561111   the order in which the fields are evaluated becomes important. In practice,
    10571112   the fields defined in this document are consistently implemented in a
    1058    single, logical order, due to the fact that entity tags are presumed to be
    1059    more accurate than date validators. For example, the only reason to send
    1060    both <x:ref>If-Modified-Since</x:ref> and <x:ref>If-None-Match</x:ref> in
    1061    the same GET request is to support intermediary caches that might not have
    1062    implemented <x:ref>If-None-Match</x:ref>, so it makes sense to ignore the
    1063    <x:ref>If-Modified-Since</x:ref> when entity tags are understood and
    1064    available for the selected representation.
    1065 </t>
    1066 <t>
    1067    The general rule of conditional precedence is that exact match conditions
    1068    are evaluated before cache-validating conditions and, within that order,
    1069    last-modified conditions are only evaluated if the corresponding
    1070    entity tag condition is not present (or not applicable because the
    1071    selected representation does not have an entity tag).
    1072 </t>
    1073 <t>
    1074    Specifically, the fields defined by this specification are evaluated
    1075    as follows:
     1113   single, logical order, since "lost update" preconditions have more strict
     1114   requirements than cache validation, a validated cache is more efficient
     1115   than a partial response, and entity tags are presumed to be more accurate
     1116   than date validators.
     1117</t>
     1118<t>
     1119   A recipient cache or origin server &MUST; evaluate the request
     1120   preconditions defined by this specification in the following order:
    10761121   <list style="numbers">
    10771122     <t anchor="precedence1">When <x:ref>If-Match</x:ref> is present, evaluate it:
Note: See TracChangeset for help on using the changeset viewer.