Changeset 2361
- Timestamp:
- 23/08/13 13:20:09 (9 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p4-conditional.html
r2358 r2361 449 449 } 450 450 @bottom-center { 451 content: "Expires February 13, 2014";451 content: "Expires February 24, 2014"; 452 452 } 453 453 @bottom-right { … … 475 475 <link rel="Chapter" title="3 Precondition Header Fields" href="#rfc.section.3"> 476 476 <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"> 482 483 <link rel="Appendix" title="A Changes from RFC 2616" href="#rfc.section.A"> 483 484 <link rel="Appendix" title="B Imported ABNF" href="#rfc.section.B"> … … 491 492 <meta name="dct.creator" content="Reschke, J. F."> 492 493 <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"> 494 495 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 495 496 <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."> … … 517 518 </tr> 518 519 <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> 521 522 </tr> 522 523 </tbody> … … 545 546 in progress”. 546 547 </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> 548 549 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 549 550 <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 584 585 </ul> 585 586 </li> 586 <li><a href="#rfc.section.3">3.</a> <a href="# header.field.definitions">Precondition Header Fields</a><ul>587 <li><a href="#rfc.section.3">3.</a> <a href="#preconditions">Precondition Header Fields</a><ul> 587 588 <li><a href="#rfc.section.3.1">3.1</a> <a href="#header.if-match">If-Match</a></li> 588 589 <li><a href="#rfc.section.3.2">3.2</a> <a href="#header.if-none-match">If-None-Match</a></li> … … 597 598 </ul> 598 599 </li> 599 <li><a href="#rfc.section.5">5.</a> <a href="#precedence">Evaluation and Precedence</a></li> 600 <li><a href="#rfc.section.6">6.</a> <a href="#IANA.considerations">IANA Considerations</a><ul> 601 <li><a href="#rfc.section.6.1">6.1</a> <a href="#status.code.registration">Status Code Registration</a></li> 602 <li><a href="#rfc.section.6.2">6.2</a> <a href="#header.field.registration">Header Field Registration</a></li> 600 <li><a href="#rfc.section.5">5.</a> <a href="#evaluation">Evaluation</a></li> 601 <li><a href="#rfc.section.6">6.</a> <a href="#precedence">Precedence</a></li> 602 <li><a href="#rfc.section.7">7.</a> <a href="#IANA.considerations">IANA Considerations</a><ul> 603 <li><a href="#rfc.section.7.1">7.1</a> <a href="#status.code.registration">Status Code Registration</a></li> 604 <li><a href="#rfc.section.7.2">7.2</a> <a href="#header.field.registration">Header Field Registration</a></li> 603 605 </ul> 604 606 </li> 605 <li><a href="#rfc.section. 7">7.</a> <a href="#security.considerations">Security Considerations</a></li>606 <li><a href="#rfc.section. 8">8.</a> <a href="#acks">Acknowledgments</a></li>607 <li><a href="#rfc.section. 9">9.</a> <a href="#rfc.references">References</a><ul>608 <li><a href="#rfc.section. 9.1">9.1</a> <a href="#rfc.references.1">Normative References</a></li>609 <li><a href="#rfc.section. 9.2">9.2</a> <a href="#rfc.references.2">Informative References</a></li>607 <li><a href="#rfc.section.8">8.</a> <a href="#security.considerations">Security Considerations</a></li> 608 <li><a href="#rfc.section.9">9.</a> <a href="#acks">Acknowledgments</a></li> 609 <li><a href="#rfc.section.10">10.</a> <a href="#rfc.references">References</a><ul> 610 <li><a href="#rfc.section.10.1">10.1</a> <a href="#rfc.references.1">Normative References</a></li> 611 <li><a href="#rfc.section.10.2">10.2</a> <a href="#rfc.references.2">Informative References</a></li> 610 612 </ul> 611 613 </li> … … 639 641 to false. 640 642 </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 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 3</a>) are evaluated when applicable to the recipient (<a href="#evaluation" title="Evaluation">Section 5</a>) according to their order of precedence (<a href="#precedence" title="Precedence">Section 6</a>). 643 644 </p> 644 645 <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a> <a id="conformance" href="#conformance">Conformance and Error Handling</a></h2> … … 932 933 </li> 933 934 </ul> 934 <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <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 5</a> defines when the preconditions are applied andthe order of evaluation when more than one precondition is present.935 <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <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 5</a> defines when the preconditions are applied. <a href="#precedence" title="Precedence">Section 6</a> defines the order of evaluation when more than one precondition is present. 936 937 </p> 937 938 <div id="rfc.iref.i.1"></div> 938 939 <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> <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 the940 target resource, when the field-value is "*", or on the selected representation having an entity-tag that matches one of those941 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 2.3.2</a>). 942 943 </p> 943 944 <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> … … 946 947 If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" 947 948 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 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 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 963 958 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 other959 agent might not be aware of it, perhaps because the prior response was lost or a compatible change was made by some other 965 960 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 966 961 change made by the same user agent. 967 962 </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> 968 966 <div id="rfc.iref.i.2"></div> 969 967 <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <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 2.3.2</a>). 982 971 </p> 983 972 <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 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> 993 974 <div id="rfc.figure.u.11"></div><pre class="text"> If-None-Match: "xyzzy" 994 975 If-None-Match: W/"xyzzy" … … 996 977 If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz" 997 978 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 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> 999 1002 <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a> <a id="header.if-modified-since" href="#header.if-modified-since">If-Modified-Since</a></h2> 1000 1003 <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 request1002 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. 1003 1006 </p> 1004 1007 <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> 1005 1008 </pre><p id="rfc.section.3.3.p.3">An example of the field is:</p> 1006 1009 <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 1024 1024 synchronized or when the server has chosen to only honor exact timestamp matches (due to a problem with Last-Modified dates 1025 1025 that appear to go "back in time" when the origin server's clock is corrected or a representation is restored from an archived … … 1027 1027 does not contain a <a href="#header.last-modified" class="smpl">Last-Modified</a> field. 1028 1028 </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 field1029 <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 1030 1030 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 1031 1031 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. 1032 1032 </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> 1038 1037 <div id="rfc.iref.i.4"></div> 1039 1038 <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a> <a id="header.if-unmodified-since" href="#header.if-unmodified-since">If-Unmodified-Since</a></h2> … … 1044 1043 </pre><p id="rfc.section.3.4.p.3">An example of the field is:</p> 1045 1044 <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 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 1061 1059 in the current state of the target resource (i.e., the change requested by the user agent has already succeeded, but the user 1062 1060 agent might not be aware of that because the prior response message was lost or a compatible change was made by some other … … 1064 1062 change made by the same user agent. 1065 1063 </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> 1066 1066 <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a> <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>. 1068 1069 </p> 1069 1070 <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="status.code.definitions" href="#status.code.definitions">Status Code Definitions</a></h1> … … 1081 1082 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). 1082 1083 </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 conditional1084 <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 1084 1085 GET to a shared proxy, then the proxy <em class="bcp14">SHOULD</em> forward the 304 response to that client. 1085 1086 </p> … … 1087 1088 <div id="rfc.iref.21"></div> 1088 1089 <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a> <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 on1090 theserver. This response code allows the client to place preconditions on the current resource state (its current representations1090 <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 1091 1092 and metadata) and thus prevent the request method from being applied if the target resource is in an unexpected state. 1092 1093 </p> 1093 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <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> <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> <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> 1123 1120 <ol> 1124 1121 <li id="precedence1">When <a href="#header.if-match" class="smpl">If-Match</a> is present, evaluate it: … … 1160 1157 </li> 1161 1158 </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 regarding1159 <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 1163 1160 the order for evaluating such fields in relation to those defined in this document and other conditionals that might be found 1164 1161 in practice. 1165 1162 </p> 1166 <h1 id="rfc.section. 6"><a href="#rfc.section.6">6.</a> <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> <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 <<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>> shall be updated with the registrations below:1163 <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <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> <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 <<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>> shall be updated with the registrations below: 1169 1166 </p> 1170 1167 <div id="rfc.table.1"> … … 1194 1191 </table> 1195 1192 </div> 1196 <h2 id="rfc.section. 6.2"><a href="#rfc.section.6.2">6.2</a> <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 <<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>>.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 to1193 <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a> <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 <<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>>. 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 1200 1197 the permanent registrations below (see <a href="#BCP90" id="rfc.xref.BCP90.1"><cite title="Registration Procedures for Message Header Fields">[BCP90]</cite></a>): 1201 1198 </p> … … 1257 1254 </table> 1258 1255 </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> <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.11256 <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> <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 1262 1259 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>. 1263 1260 </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 malicious1261 <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 1265 1262 changes, or detect man-in-the-middle attacks. At best, they enable more efficient cache updates and optimistic concurrent 1266 1263 writes when all participants are behaving nicely. At worst, the conditions will fail and the client will receive a response 1267 1264 that is no more harmful than an HTTP exchange without conditional requests. 1268 1265 </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 semantically1266 <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 1270 1267 invalid entity-tag that is unique to the user or user agent, send it in a cacheable response with a long freshness time, and 1271 1268 then read that entity-tag in later conditional requests as a means of re-identifying that user or user agent. Such an identifying … … 1274 1271 actions, such as clearing stored cookies or changing to a private browsing mode. 1275 1272 </p> 1276 <h1 id="rfc.section. 8"><a href="#rfc.section.8">8.</a> <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> References1273 <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a> <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 1280 1277 </h1> 1281 <h2 id="rfc.references.1"><a href="#rfc.section. 9.1" id="rfc.section.9.1">9.1</a> Normative References1278 <h2 id="rfc.references.1"><a href="#rfc.section.10.1" id="rfc.section.10.1">10.1</a> Normative References 1282 1279 </h2> 1283 1280 <table> … … 1313 1310 </tr> 1314 1311 </table> 1315 <h2 id="rfc.references.2"><a href="#rfc.section. 9.2" id="rfc.section.9.2">9.2</a> Informative References1312 <h2 id="rfc.references.2"><a href="#rfc.section.10.2" id="rfc.section.10.2">10.2</a> Informative References 1316 1313 </h2> 1317 1314 <table> … … 1351 1348 situations (such as a PUT response). (<a href="#header.etag" id="rfc.xref.header.etag.4" title="ETag">Section 2.3</a>) 1352 1349 </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 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 6</a>) 1354 1351 </p> 1355 1352 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="imported.abnf" href="#imported.abnf">Imported ABNF</a></h1> … … 1463 1460 <ul class="ind"> 1464 1461 <li><a id="rfc.index.3" href="#rfc.index.3"><b>3</b></a><ul> 1465 <li>304 Not Modified (status code) <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) <a href="#rfc.iref.21"><b>4.1</b></a>, <a href="#rfc.xref.status.304.1">7.1</a></li> 1466 1463 </ul> 1467 1464 </li> 1468 1465 <li><a id="rfc.index.4" href="#rfc.index.4"><b>4</b></a><ul> 1469 <li>412 Precondition Failed (status code) <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) <a href="#rfc.iref.21"><b>4.2</b></a>, <a href="#rfc.xref.status.412.1">7.1</a></li> 1470 1467 </ul> 1471 1468 </li> 1472 1469 <li><a id="rfc.index.B" href="#rfc.index.B"><b>B</b></a><ul> 1473 <li><em>BCP90</em> <a href="#rfc.xref.BCP90.1"> 6.2</a>, <a href="#BCP90"><b>9.2</b></a></li>1470 <li><em>BCP90</em> <a href="#rfc.xref.BCP90.1">7.2</a>, <a href="#BCP90"><b>10.2</b></a></li> 1474 1471 </ul> 1475 1472 </li> 1476 1473 <li><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul> 1477 <li>ETag header field <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 <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> 1478 1475 </ul> 1479 1476 </li> … … 1496 1493 </li> 1497 1494 <li><a id="rfc.index.I" href="#rfc.index.I"><b>I</b></a><ul> 1498 <li>If-Match header field <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 <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 <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 <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 <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 <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 <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 <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> 1502 1499 </ul> 1503 1500 </li> 1504 1501 <li><a id="rfc.index.L" href="#rfc.index.L"><b>L</b></a><ul> 1505 <li>Last-Modified header field <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 <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> 1506 1503 </ul> 1507 1504 </li> … … 1511 1508 </li> 1512 1509 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 1513 <li><em>Part1</em> <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> <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> 1514 1511 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.10">C</a></li> 1515 1512 <li><em>Section 2.5</em> <a href="#rfc.xref.Part1.2">1.1</a></li> … … 1518 1515 <li><em>Section 4</em> <a href="#rfc.xref.Part1.4">2.3.3</a></li> 1519 1516 <li><em>Section 7</em> <a href="#rfc.xref.Part1.3">1.2</a></li> 1520 <li><em>Section 10</em> <a href="#rfc.xref.Part1.6"> 8</a></li>1517 <li><em>Section 10</em> <a href="#rfc.xref.Part1.6">9</a></li> 1521 1518 </ul> 1522 1519 </li> 1523 <li><em>Part2</em> <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> <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> 1524 1521 <li><em>Section 3</em> <a href="#rfc.xref.Part2.2">1</a></li> 1525 1522 <li><em>Section 3.4</em> <a href="#rfc.xref.Part2.3">2.3.3</a></li> … … 1529 1526 </ul> 1530 1527 </li> 1531 <li><em>Part5</em> <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> <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> 1532 1529 <li><em>Section 3.2</em> <a href="#rfc.xref.Part5.1">3.5</a></li> 1533 1530 </ul> 1534 1531 </li> 1535 <li><em>Part6</em> <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> <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> <a href="#rfc.xref.Part6. 6">4.1</a></li>1532 <li><em>Part6</em> <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> <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> <a href="#rfc.xref.Part6.8">4.1</a></li> 1538 1535 </ul> 1539 1536 </li> … … 1541 1538 </li> 1542 1539 <li><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul> 1543 <li><em>RFC2119</em> <a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b> 9.1</b></a></li>1544 <li><em>RFC2616</em> <a href="#rfc.xref.RFC2616.1">2.3</a>, <a href="#RFC2616"><b> 9.2</b></a><ul>1540 <li><em>RFC2119</em> <a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>10.1</b></a></li> 1541 <li><em>RFC2616</em> <a href="#rfc.xref.RFC2616.1">2.3</a>, <a href="#RFC2616"><b>10.2</b></a><ul> 1545 1542 <li><em>Section 3.11</em> <a href="#rfc.xref.RFC2616.1">2.3</a></li> 1546 1543 </ul> 1547 1544 </li> 1548 <li><em>RFC4918</em> <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> <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> 1549 1546 <li><em>Section 10.4</em> <a href="#rfc.xref.RFC4918.2">5</a></li> 1550 1547 </ul> 1551 1548 </li> 1552 <li><em>RFC5234</em> <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> <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> 1553 1550 <li><em>Appendix B.1</em> <a href="#rfc.xref.RFC5234.2">B</a></li> 1554 1551 </ul> -
draft-ietf-httpbis/latest/p4-conditional.xml
r2358 r2361 151 151 </t> 152 152 <t> 153 The conditional request preconditions defined by this specification are154 evaluated by comparing the validators provided in the conditional request155 header fields to the current validators for the selected representation156 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"/>). 157 157 </t> 158 158 … … 650 650 </section> 651 651 652 <section title="Precondition Header Fields" anchor=" header.field.definitions">652 <section title="Precondition Header Fields" anchor="preconditions"> 653 653 <t> 654 654 This section defines the syntax and semantics of HTTP/1.1 header fields 655 655 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. 658 659 </t> 659 660 … … 662 663 <x:anchor-alias value="If-Match"/> 663 664 <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"/>). 668 673 </t> 669 674 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-Match"/> … … 679 684 </artwork></figure> 680 685 <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: 716 705 a) the <x:ref>412 (Precondition Failed)</x:ref> status code; or, 717 706 b) one of the <x:ref>2xx (Successful)</x:ref> status codes if the origin … … 719 708 state is already reflected in the current state of the target resource 720 709 (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 message710 the user agent might not be aware of it, perhaps because the prior response 722 711 was lost or a compatible change was made by some other user agent). 723 712 In the latter case, the origin server &MUST-NOT; send a validator header … … 725 714 of an immediately prior change made by the same user agent. 726 715 </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> 727 729 </section> 728 730 … … 731 733 <x:anchor-alias value="If-None-Match"/> 732 734 <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> 737 756 <t> 738 757 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. 745 765 </t> 746 766 <t> … … 753 773 resource. 754 774 </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> 790 813 </section> 791 814 … … 796 819 The "If-Modified-Since" header field can be used with GET or HEAD to make 797 820 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. 800 826 </t> 801 827 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-Modified-Since"/> … … 809 835 </artwork></figure> 810 836 <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. 836 863 </t> 837 864 <t> … … 857 884 only those changed during the specified window. 858 885 </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> 868 908 </section> 869 909 … … 888 928 </artwork></figure> 889 929 <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 897 939 received field-value is not a valid HTTP-date. 898 940 </t> 899 941 <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: 923 964 a) the <x:ref>412 (Precondition Failed)</x:ref> status code; or, 924 965 b) one of the <x:ref>2xx (Successful)</x:ref> status codes if the origin … … 932 973 of an immediately prior change made by the same user agent. 933 974 </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> 934 989 </section> 935 990 … … 937 992 <t> 938 993 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;. 942 999 </t> 943 1000 </section> … … 998 1055 <t> 999 1056 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 false1057 or more conditions given in the request header fields evaluated to false 1001 1058 when tested on the server. This response code allows the client to place 1002 1059 preconditions on the current resource state (its current representations … … 1007 1064 </section> 1008 1065 1009 <section title="Evaluation and Precedence" anchor="precedence">1010 <t> 1011 For each conditional request, a server &MUST; evaluate therequest1066 <section title="Evaluation" anchor="evaluation"> 1067 <t> 1068 Except when excluded below, a server &MUST; evaluate received request 1012 1069 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> 1041 1104 response. 1042 1105 </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"> 1054 1109 <t> 1055 1110 When more than one conditional request header field is present in a request, 1056 1111 the order in which the fields are evaluated becomes important. In practice, 1057 1112 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: 1076 1121 <list style="numbers"> 1077 1122 <t anchor="precedence1">When <x:ref>If-Match</x:ref> is present, evaluate it:
Note: See TracChangeset
for help on using the changeset viewer.