Changeset 2128 for draft-ietf-httpbis/latest/p4-conditional.html
- Timestamp:
- 19/01/13 13:53:26 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p4-conditional.html
r2116 r2128 449 449 } 450 450 @bottom-center { 451 content: "Expires July 16, 2013";451 content: "Expires July 23, 2013"; 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 Precedence" href="#rfc.section.5">477 <link rel="Chapter" title="5 Evaluation and Precedence" href="#rfc.section.5"> 478 478 <link rel="Chapter" title="6 IANA Considerations" href="#rfc.section.6"> 479 479 <link rel="Chapter" title="7 Security Considerations" href="#rfc.section.7"> … … 491 491 <meta name="dct.creator" content="Reschke, J. F."> 492 492 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest"> 493 <meta name="dct.issued" scheme="ISO8601" content="2013-01-1 2">493 <meta name="dct.issued" scheme="ISO8601" content="2013-01-19"> 494 494 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 495 495 <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 517 </tr> 518 518 <tr> 519 <td class="left">Expires: July 16, 2013</td>520 <td class="right">January 1 2, 2013</td>519 <td class="left">Expires: July 23, 2013</td> 520 <td class="right">January 19, 2013</td> 521 521 </tr> 522 522 </tbody> … … 545 545 in progress”. 546 546 </p> 547 <p>This Internet-Draft will expire on July 16, 2013.</p>547 <p>This Internet-Draft will expire on July 23, 2013.</p> 548 548 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 549 549 <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 581 581 </ul> 582 582 </li> 583 <li><a href="#rfc.section.2.4">2.4</a> <a href="# rules.for.when.to.use.entity.tags.and.last-modified.dates">Rules forWhen to Use Entity-tags and Last-Modified Dates</a></li>583 <li><a href="#rfc.section.2.4">2.4</a> <a href="#when.to.use.entity.tags.and.last-modified.dates">When to Use Entity-tags and Last-Modified Dates</a></li> 584 584 </ul> 585 585 </li> … … 597 597 </ul> 598 598 </li> 599 <li><a href="#rfc.section.5">5.</a> <a href="#precedence"> Precedence</a></li>599 <li><a href="#rfc.section.5">5.</a> <a href="#precedence">Evaluation and Precedence</a></li> 600 600 <li><a href="#rfc.section.6">6.</a> <a href="#IANA.considerations">IANA Considerations</a><ul> 601 601 <li><a href="#rfc.section.6.1">6.1</a> <a href="#status.code.registration">Status Code Registration</a></li> … … 666 666 in use and imposes restrictions on when weak validators can be used as preconditions. 667 667 </p> 668 <p id="rfc.section.2.1.p.2">A "strong validator" is a representation metadata value that <em class="bcp14">MUST</em> be changed to a new, previously unused or guaranteed unique, value whenever a change occurs to the representation data such 669 that a change would be observable in the payload body of a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to GET. 670 </p> 671 <p id="rfc.section.2.1.p.3">A strong validator <em class="bcp14">MAY</em> be changed for other reasons, such as when a semantically significant part of the representation metadata is changed (e.g., <a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a>), but it is in the best interests of the origin server to only change the value when it is necessary to invalidate the stored 672 responses held by remote caches and authoring tools. A strong validator <em class="bcp14">MUST</em> be unique across all representations of a given resource, such that no two representations of that resource share the same 673 validator unless their payload body would be identical. 668 <p id="rfc.section.2.1.p.2">A "strong validator" is a representation metadata value that is changed to a new, previously unused or guaranteed unique, 669 value whenever a change occurs to the representation data such that a change would be observable in the payload body of a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to GET. 670 </p> 671 <p id="rfc.section.2.1.p.3">A strong validator might change for other reasons, such as when a semantically significant part of the representation metadata 672 is changed (e.g., <a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a>), but it is in the best interests of the origin server to only change the value when it is necessary to invalidate the stored 673 responses held by remote caches and authoring tools. A strong validator is unique across all representations of a given resource, 674 such that no two representations of that resource share the same validator unless their payload body would be identical. 674 675 </p> 675 676 <p id="rfc.section.2.1.p.4">Cache entries might persist for arbitrarily long periods, regardless of expiration times. Thus, a cache might attempt to validate 676 an entry using a validator that it obtained in the distant past. A strong validator <em class="bcp14">MUST</em> be unique across all versions of all representations associated with a particular resource over time. However, there is no 677 implication of uniqueness across representations of different resources (i.e., the same strong validator might be in use for 678 representations of multiple resources at the same time and does not imply that those representations are equivalent). 677 an entry using a validator that it obtained in the distant past. A strong validator is unique across all versions of all representations 678 associated with a particular resource over time. However, there is no implication of uniqueness across representations of 679 different resources (i.e., the same strong validator might be in use for representations of multiple resources at the same 680 time and does not imply that those representations are equivalent). 679 681 </p> 680 682 <p id="rfc.section.2.1.p.5">There are a variety of strong validators used in practice. The best are based on strict revision control, wherein each change … … 791 793 ETag: "" 792 794 </pre><p id="rfc.section.2.3.p.6">An entity-tag can be either a weak or strong validator, with strong being the default. If an origin server provides an entity-tag 793 for a representation and the generation of that entity-tag does not satisfy the requirements for a strong validator (<a href="#weak.and.strong.validators" title="Weak versus Strong">Section 2.1</a>), then th at entity-tag <em class="bcp14">MUST</em> be markedas weak by prefixing its opaque value with "W/" (case-sensitive).795 for a representation and the generation of that entity-tag does not satisfy the requirements for a strong validator (<a href="#weak.and.strong.validators" title="Weak versus Strong">Section 2.1</a>), then the origin server <em class="bcp14">MUST</em> mark the entity-tag as weak by prefixing its opaque value with "W/" (case-sensitive). 794 796 </p> 795 797 <h3 id="rfc.section.2.3.1"><a href="#rfc.section.2.3.1">2.3.1</a> <a id="entity.tag.generation" href="#entity.tag.generation">Generation</a></h3> … … 813 815 </p> 814 816 <ul> 815 <li>The strong comparison function: in order to be considered equal, both opaque-tags <em class="bcp14">MUST</em> be identical character-by-character, and both <em class="bcp14">MUST NOT</em> be weak. 816 </li> 817 <li>The weak comparison function: in order to be considered equal, both opaque-tags <em class="bcp14">MUST</em> be identical character-by-character, but either or both of them <em class="bcp14">MAY</em> be tagged as "weak" without affecting the result. 817 <li><dfn>Strong comparison</dfn>: two entity-tags are equivalent if both are not weak and their opaque-tags match character-by-character. 818 </li> 819 <li><dfn>Weak comparison</dfn>: two entity-tags are equivalent if their opaque-tags match character-by-character, regardless of either or both being tagged 820 as "weak". 818 821 </li> 819 822 </ul> … … 895 898 </p> 896 899 </div> 897 <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a> <a id=" rules.for.when.to.use.entity.tags.and.last-modified.dates" href="#rules.for.when.to.use.entity.tags.and.last-modified.dates">Rules forWhen to Use Entity-tags and Last-Modified Dates</a></h2>900 <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a> <a id="when.to.use.entity.tags.and.last-modified.dates" href="#when.to.use.entity.tags.and.last-modified.dates">When to Use Entity-tags and Last-Modified Dates</a></h2> 898 901 <p id="rfc.section.2.4.p.1">We adopt a set of rules and recommendations for origin servers, clients, and caches regarding when various validator types 899 902 ought to be used, and for what purposes. 900 903 </p> 901 <p id="rfc.section.2.4.p.2">HTTP/1.1 origin servers: </p> 904 <p id="rfc.section.2.4.p.2">In <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> responses to GET or HEAD, an origin server: 905 </p> 902 906 <ul> 903 907 <li><em class="bcp14">SHOULD</em> send an entity-tag validator unless it is not feasible to generate one. … … 909 913 </li> 910 914 </ul> 911 <p id="rfc.section.2.4.p.3">In other words, the preferred behavior for an HTTP/1.1 origin server is to send both a strong entity-tag and a <a href="#header.last-modified" class="smpl">Last-Modified</a> value.912 </p> 913 <p id="rfc.section.2.4.p.4"> HTTP/1.1 clients: </p>915 <p id="rfc.section.2.4.p.3">In other words, the preferred behavior for an origin server is to send both a strong entity-tag and a <a href="#header.last-modified" class="smpl">Last-Modified</a> value in successful responses to a retrieval request. 916 </p> 917 <p id="rfc.section.2.4.p.4">A client: </p> 914 918 <ul> 915 919 <li><em class="bcp14">MUST</em> use that entity-tag in any cache-conditional request (using <a href="#header.if-match" class="smpl">If-Match</a> or <a href="#header.if-none-match" class="smpl">If-None-Match</a>) if an entity-tag has been provided by the origin server. … … 922 926 </li> 923 927 </ul> 924 <p id="rfc.section.2.4.p.5">An HTTP/1.1 origin server, upon receiving a conditional request that includes both a Last-Modified date (e.g., in an <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a> or <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> header field) and one or more entity-tags (e.g., in an <a href="#header.if-match" class="smpl">If-Match</a>, <a href="#header.if-none-match" class="smpl">If-None-Match</a>, or <a href="p5-range.html#header.if-range" class="smpl">If-Range</a> header field) as cache validators, <em class="bcp14">MUST NOT</em> send a response status code of <a href="#status.304" class="smpl">304 (Not Modified)</a> unless doing so is consistent with all of the conditional header fields in the request.925 </p>926 <p id="rfc.section.2.4.p.6">An HTTP/1.1 caching proxy, upon receiving a conditional request that includes both a Last-Modified date and one or more entity-tags927 as cache validators, <em class="bcp14">MUST NOT</em> send a locally cached response to the client unless that cached response is consistent with all of the conditional header928 fields in the request.929 </p>930 <ul class="empty">931 <li> <b>Note:</b> The general principle behind these rules is that HTTP/1.1 servers and clients ought to transmit as much non-redundant information932 as is available in their responses and requests. HTTP/1.1 systems receiving this information will make the most conservative933 assumptions about the validators they receive.934 </li>935 <li>HTTP/1.0 clients and caches might ignore entity-tags. Generally, last-modified values received or used by these systems will936 support transparent and efficient caching, and so HTTP/1.1 origin servers still ought to provide Last-Modified values.937 </li>938 </ul>939 928 <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> 940 <p id="rfc.section.3.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields for applying preconditions on requests. <a href="#precedence" title=" Precedence">Section 5</a> defines the order of evaluation when more than one precondition is present in a request.929 <p id="rfc.section.3.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields for applying preconditions on requests. <a href="#precedence" title="Evaluation and Precedence">Section 5</a> defines when the preconditions are applied and the order of evaluation when more than one precondition is present. 941 930 </p> 942 931 <div id="rfc.iref.i.1"></div> … … 953 942 of the selected representation for the target resource (as per <a href="#entity.tag.comparison" title="Comparison">Section 2.3.2</a>), or if "*" is given and any current representation exists for the target resource. 954 943 </p> 955 <p id="rfc.section.3.1.p.5">If the condition is met, the server <em class="bcp14">MAY</em> perform the request method as if the If-Match header field was not present.944 <p id="rfc.section.3.1.p.5">If the condition is met, the server <em class="bcp14">MAY</em> perform the request method. 956 945 </p> 957 946 <p id="rfc.section.3.1.p.6">Origin servers <em class="bcp14">MUST NOT</em> perform the requested method if the condition is not met; instead they <em class="bcp14">MUST</em> respond with the <a href="#status.412" class="smpl">412 (Precondition … … 960 949 <p id="rfc.section.3.1.p.7">Proxy servers using a cached response as the selected representation <em class="bcp14">MUST NOT</em> perform the requested method if the condition is not met; instead, they <em class="bcp14">MUST</em> forward the request towards the origin server. 961 950 </p> 962 <p id="rfc.section.3.1.p.8">If the request would, without the If-Match header field, result in anything other than a <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> or <a href="#status.412" class="smpl">412 (Precondition Failed)</a> status code, then the If-Match header field <em class="bcp14">MUST</em> be ignored. 963 </p> 964 <p id="rfc.section.3.1.p.9">Examples:</p> 951 <p id="rfc.section.3.1.p.8">Examples:</p> 965 952 <div id="rfc.figure.u.9"></div><pre class="text"> If-Match: "xyzzy" 966 953 If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" … … 986 973 </p> 987 974 <p id="rfc.section.3.2.p.6">If the condition is not met, the server <em class="bcp14">MUST NOT</em> perform the requested method. Instead, if the request method was GET or HEAD, the server <em class="bcp14">SHOULD</em> respond with a <a href="#status.304" class="smpl">304 (Not Modified)</a> status code, including the cache-related header fields (particularly <a href="#header.etag" class="smpl">ETag</a>) of the selected representation that has a matching entity-tag. For all other request methods, the server <em class="bcp14">MUST</em> respond with a <a href="#status.412" class="smpl">412 (Precondition 988 Failed)</a> status code. 989 </p> 990 <p id="rfc.section.3.2.p.7">If the condition is met, the server <em class="bcp14">MAY</em> perform the requested method as if the If-None-Match header field did not exist, but <em class="bcp14">MUST</em> also ignore any <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a> header field(s) in the request. That is, if no entity-tags match, then the server <em class="bcp14">MUST NOT</em> send a <a href="#status.304" class="smpl">304 991 (Not Modified)</a> response. 992 </p> 993 <p id="rfc.section.3.2.p.8">If the request would, without the If-None-Match header field, result in anything other than a <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> or <a href="#status.304" class="smpl">304 (Not Modified)</a> status code, then the If-None-Match header field <em class="bcp14">MUST</em> be ignored. (See <a href="#rules.for.when.to.use.entity.tags.and.last-modified.dates" title="Rules for When to Use Entity-tags and Last-Modified Dates">Section 2.4</a> for a discussion of server behavior when both <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a> and If-None-Match appear in the same request.) 994 </p> 995 <p id="rfc.section.3.2.p.9">Examples:</p> 975 Failed)</a> status code when the condition is not met. 976 </p> 977 <p id="rfc.section.3.2.p.7">If the condition is met, the server <em class="bcp14">MAY</em> perform the requested method and <em class="bcp14">MUST</em> ignore any <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a> header field(s) in the request. That is, if no entity-tags match, then the server <em class="bcp14">MUST NOT</em> send a <a href="#status.304" class="smpl">304 (Not Modified)</a> response. 978 </p> 979 <p id="rfc.section.3.2.p.8">Examples:</p> 996 980 <div id="rfc.figure.u.11"></div><pre class="text"> If-None-Match: "xyzzy" 997 981 If-None-Match: W/"xyzzy" … … 1044 1028 <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> 1045 1029 <p id="rfc.section.3.4.p.1">The "If-Unmodified-Since" header field can be used to make a request method conditional by modification date: if the selected 1046 representation has been modified since the time specified in this field, then the server <em class="bcp14">MUST NOT</em> perform the requested operation and <em class="bcp14">MUST</em> instead respond with the <a href="#status.412" class="smpl">412 (Precondition Failed)</a> status code. If the selected representation has not been modified since the time specified in this field, the server <em class="bcp14"> SHOULD</em> perform the request method as if the If-Unmodified-Since header field were not present.1030 representation has been modified since the time specified in this field, then the server <em class="bcp14">MUST NOT</em> perform the requested operation and <em class="bcp14">MUST</em> instead respond with the <a href="#status.412" class="smpl">412 (Precondition Failed)</a> status code. If the selected representation has not been modified since the time specified in this field, the server <em class="bcp14">MAY</em> perform the request. 1047 1031 </p> 1048 1032 <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.10"></span> <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> = <a href="#imported.abnf" class="smpl">HTTP-date</a> 1049 1033 </pre><p id="rfc.section.3.4.p.3">An example of the field is:</p> 1050 1034 <div id="rfc.figure.u.15"></div><pre class="text"> If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT 1051 </pre><p id="rfc.section.3.4.p.5">If a request normally (i.e., in absence of the If-Unmodified-Since header field) would result in anything other than a <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> or <a href="#status.412" class="smpl">412 (Precondition Failed)</a> status code, the If-Unmodified-Since header field <em class="bcp14">SHOULD</em> be ignored. 1052 </p> 1053 <p id="rfc.section.3.4.p.6">If the specified date is invalid, the header field <em class="bcp14">MUST</em> be ignored. 1035 </pre><p id="rfc.section.3.4.p.5">A server <em class="bcp14">MUST</em> ignore the If-Unmodified-Since header field if the received value is not a valid HTTP-date. 1054 1036 </p> 1055 1037 <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> … … 1080 1062 and metadata) and thus prevent the request method from being applied if the target resource is in an unexpected state. 1081 1063 </p> 1082 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="precedence" href="#precedence">Precedence</a></h1> 1083 <p id="rfc.section.5.p.1">When more than one conditional request header field is present in a request, the order in which the fields are evaluated becomes 1064 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="precedence" href="#precedence">Evaluation and Precedence</a></h1> 1065 <p id="rfc.section.5.p.1">For each conditional request, a server <em class="bcp14">MUST</em> evaluate the request preconditions after it has successfully performed its normal request checks (i.e., just before it would 1066 perform the action associated with the request method). Preconditions are ignored if the server determines that an error or 1067 redirect response applies before they are evaluated. 1068 </p> 1069 <p id="rfc.section.5.p.2">When more than one conditional request header field is present in a request, the order in which the fields are evaluated becomes 1084 1070 important. In practice, the fields defined in this document are consistently implemented in a single, logical order, due to 1085 1071 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. 1086 1072 </p> 1087 <p id="rfc.section.5.p. 2">The general rule of conditional precedence is that exact match conditions are evaluated before cache-validating conditions1073 <p id="rfc.section.5.p.3">The general rule of conditional precedence is that exact match conditions are evaluated before cache-validating conditions 1088 1074 and, within that order, last-modified conditions are only evaluated if the corresponding entity tag condition is not present 1089 1075 (or not applicable because the selected representation does not have an entity tag). 1090 1076 </p> 1091 <p id="rfc.section.5.p. 3">Specifically, the fields defined by this specification are evaluated as follows: </p>1077 <p id="rfc.section.5.p.4">Specifically, the fields defined by this specification are evaluated as follows: </p> 1092 1078 <ol> 1093 1079 <li>When <a href="#header.if-match" class="smpl">If-Match</a> is present, evaluate it: … … 1123 1109 </li> 1124 1110 </ol> 1125 <p id="rfc.section.5.p. 4">Any extension to HTTP/1.1 that defines additional conditional request header fields ought to define its own expectations regarding1111 <p id="rfc.section.5.p.5">Any extension to HTTP/1.1 that defines additional conditional request header fields ought to define its own expectations regarding 1126 1112 the order for evaluating such fields in relation to those defined in this document and other conditionals that might be found 1127 1113 in practice. … … 1305 1291 situations (such as a PUT response). (<a href="#header.etag" id="rfc.xref.header.etag.4" title="ETag">Section 2.3</a>) 1306 1292 </p> 1307 <p id="rfc.section.A.p.5">The precedence for evaluation of conditional requests has been defined. (<a href="#precedence" title=" Precedence">Section 5</a>)1293 <p id="rfc.section.A.p.5">The precedence for evaluation of conditional requests has been defined. (<a href="#precedence" title="Evaluation and Precedence">Section 5</a>) 1308 1294 </p> 1309 1295 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="imported.abnf" href="#imported.abnf">Imported ABNF</a></h1>
Note: See TracChangeset
for help on using the changeset viewer.