Ignore:
Timestamp:
23/08/13 13:20:09 (7 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

File:
1 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>
Note: See TracChangeset for help on using the changeset viewer.