Changeset 2671 for draft-ietf-httpbis
- Timestamp:
- 14/05/14 12:58:12 (7 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p4-conditional.html
r2667 r2671 463 463 } 464 464 @bottom-center { 465 content: "Expires November 1 3, 2014";465 content: "Expires November 15, 2014"; 466 466 } 467 467 @bottom-right { … … 506 506 <meta name="dct.creator" content="Reschke, J. F."> 507 507 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest"> 508 <meta name="dct.issued" scheme="ISO8601" content="2014-05-1 2">508 <meta name="dct.issued" scheme="ISO8601" content="2014-05-14"> 509 509 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 510 510 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is a stateless 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."> … … 532 532 </tr> 533 533 <tr> 534 <td class="left">Expires: November 1 3, 2014</td>535 <td class="right">May 1 2, 2014</td>534 <td class="left">Expires: November 15, 2014</td> 535 <td class="right">May 14, 2014</td> 536 536 </tr> 537 537 </tbody> … … 561 561 in progress”. 562 562 </p> 563 <p>This Internet-Draft will expire on November 1 3, 2014.</p>563 <p>This Internet-Draft will expire on November 15, 2014.</p> 564 564 </div> 565 565 <div id="rfc.copyrightnotice"> … … 597 597 <li><a href="#rfc.section.2.3.1">2.3.1</a> <a href="#entity.tag.generation">Generation</a></li> 598 598 <li><a href="#rfc.section.2.3.2">2.3.2</a> <a href="#entity.tag.comparison">Comparison</a></li> 599 <li><a href="#rfc.section.2.3.3">2.3.3</a> <a href="#example.entity.tag.vs.conneg">Example: Entity- tags Varying on Content-Negotiated Resources</a></li>599 <li><a href="#rfc.section.2.3.3">2.3.3</a> <a href="#example.entity.tag.vs.conneg">Example: Entity-Tags Varying on Content-Negotiated Resources</a></li> 600 600 </ul> 601 601 </li> 602 <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>602 <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> 603 603 </ul> 604 604 </li> … … 674 674 <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a href="#validators">Validators</a></h1> 675 675 <p id="rfc.section.2.p.1">This specification defines two forms of metadata that are commonly used to observe resource state and test for preconditions: 676 modification dates (<a href="#header.last-modified" id="rfc.xref.header.last-modified.1" title="Last-Modified">Section 2.2</a>) and opaque entity tags (<a href="#header.etag" id="rfc.xref.header.etag.1" title="ETag">Section 2.3</a>). Additional metadata that reflects resource state has been defined by various extensions of HTTP, such as WebDAV <a href="#RFC4918" id="rfc.xref.RFC4918.1"><cite title="HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)">[RFC4918]</cite></a>, that are beyond the scope of this specification. A resource metadata value is referred to as a "<dfn>validator</dfn>" when it is used within a precondition. 676 modification dates (<a href="#header.last-modified" id="rfc.xref.header.last-modified.1" title="Last-Modified">Section 2.2</a>) and opaque entity tags (<a href="#header.etag" id="rfc.xref.header.etag.1" title="ETag">Section 2.3</a>). Additional metadata that reflects resource state has been defined by various extensions of HTTP, such as Web Distributed 677 Authoring and Versioning (WebDAV, <a href="#RFC4918" id="rfc.xref.RFC4918.1"><cite title="HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)">[RFC4918]</cite></a>), that are beyond the scope of this specification. A resource metadata value is referred to as a "<dfn>validator</dfn>" when it is used within a precondition. 677 678 </p> 678 679 <div id="weak.and.strong.validators"> … … 707 708 </p> 708 709 <p id="rfc.section.2.1.p.6">In contrast, a "weak validator" is representation metadata that might not change for every change to the representation data. 709 This weakness might be due to limitations in how the value is calculated, such as clock resolution oran inability to ensure710 uniqueness for all possible representations of the resource, or due to a desire by the resource owner to group representations711 bysome self-determined set of equivalency rather than unique sequences of data. An origin server <em class="bcp14">SHOULD</em> change a weak entity-tag whenever it considers prior representations to be unacceptable as a substitute for the current representation.710 This weakness might be due to limitations in how the value is calculated, such as clock resolution, an inability to ensure 711 uniqueness for all possible representations of the resource, or a desire of the resource owner to group representations by 712 some self-determined set of equivalency rather than unique sequences of data. An origin server <em class="bcp14">SHOULD</em> change a weak entity-tag whenever it considers prior representations to be unacceptable as a substitute for the current representation. 712 713 In other words, a weak entity-tag ought to change whenever the origin server wants caches to invalidate old responses. 713 714 </p> … … 791 792 <p id="rfc.section.2.2.2.p.4">This method relies on the fact that if two different responses were sent by the origin server during the same second, but 792 793 both had the same Last-Modified time, then at least one of those responses would have a <a href="p2-semantics.html#header.date" class="smpl">Date</a> value equal to its Last-Modified time. The arbitrary 60-second limit guards against the possibility that the Date and Last-Modified 793 values are generated from different clocks ,or at somewhat different times during the preparation of the response. An implementation <em class="bcp14">MAY</em> use a value larger than 60 seconds, if it is believed that 60 seconds is too short.794 values are generated from different clocks or at somewhat different times during the preparation of the response. An implementation <em class="bcp14">MAY</em> use a value larger than 60 seconds, if it is believed that 60 seconds is too short. 794 795 </p> 795 796 </div> … … 812 813 ; <a href="#imported.abnf" class="smpl">VCHAR</a> except double quotes, plus obs-text 813 814 </pre><div class="note" id="rfc.section.2.3.p.3"> 814 <p><b>Note:</b> Previously, opaque-tag was defined to be a quoted-string (<a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, <a href="http://tools.ietf.org/html/rfc2616#section-3.11">Section 3.11</a>) , thussome recipients might perform backslash unescaping. Servers therefore ought to avoid backslash characters in entity815 <p><b>Note:</b> Previously, opaque-tag was defined to be a quoted-string (<a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, <a href="http://tools.ietf.org/html/rfc2616#section-3.11">Section 3.11</a>); thus, some recipients might perform backslash unescaping. Servers therefore ought to avoid backslash characters in entity 815 816 tags. 816 817 </p> … … 840 841 or a modification timestamp that has sub-second resolution. 841 842 </p> 842 <p id="rfc.section.2.3.1.p.3">An origin server <em class="bcp14">SHOULD</em> send ETag for any selected representation for which detection of changes can be reasonably and consistently determined, since843 the entity-tag's use in conditional requests and evaluating cache freshness (<a href="#RFC7234" id="rfc.xref.RFC7234.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a>) can result in a substantial reduction of HTTP network traffic and can be a significant factor in improving service scalability843 <p id="rfc.section.2.3.1.p.3">An origin server <em class="bcp14">SHOULD</em> send an ETag for any selected representation for which detection of changes can be reasonably and consistently determined, 844 since the entity-tag's use in conditional requests and evaluating cache freshness (<a href="#RFC7234" id="rfc.xref.RFC7234.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a>) can result in a substantial reduction of HTTP network traffic and can be a significant factor in improving service scalability 844 845 and reliability. 845 846 </p> … … 847 848 <div id="entity.tag.comparison"> 848 849 <h3 id="rfc.section.2.3.2"><a href="#rfc.section.2.3.2">2.3.2</a> <a href="#entity.tag.comparison">Comparison</a></h3> 849 <p id="rfc.section.2.3.2.p.1">There are two entity-tag comparison functions, depending on whether the comparison context allows the use of weak validators 850 or not: 851 </p> 850 <p id="rfc.section.2.3.2.p.1">There are two entity-tag comparison functions, depending on whether or not the comparison context allows the use of weak validators: </p> 852 851 <ul> 853 852 <li><dfn>Strong comparison</dfn>: two entity-tags are equivalent if both are not weak and their opaque-tags match character-by-character. … … 857 856 </li> 858 857 </ul> 859 <p id="rfc.section.2.3.2.p.2">The example below shows the results for a set of entity-tag pairs ,and both the weak and strong comparison function results:</p>858 <p id="rfc.section.2.3.2.p.2">The example below shows the results for a set of entity-tag pairs and both the weak and strong comparison function results:</p> 860 859 <div id="rfc.table.u.1"> 861 860 <table class="tt full left" cellpadding="3" cellspacing="0"> … … 898 897 </div> 899 898 <div id="example.entity.tag.vs.conneg"> 900 <h3 id="rfc.section.2.3.3"><a href="#rfc.section.2.3.3">2.3.3</a> <a href="#example.entity.tag.vs.conneg">Example: Entity- tags Varying on Content-Negotiated Resources</a></h3>899 <h3 id="rfc.section.2.3.3"><a href="#rfc.section.2.3.3">2.3.3</a> <a href="#example.entity.tag.vs.conneg">Example: Entity-Tags Varying on Content-Negotiated Resources</a></h3> 901 900 <p id="rfc.section.2.3.3.p.1">Consider a resource that is subject to content negotiation (<a href="p2-semantics.html#content.negotiation" title="Content Negotiation">Section 3.4</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>), and where the representations sent in response to a GET request vary based on the <a href="p2-semantics.html#header.accept-encoding" class="smpl">Accept-Encoding</a> request header field (<a href="p2-semantics.html#header.accept-encoding" title="Accept-Encoding">Section 5.3.4</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>): 902 901 </p> … … 939 938 </div> 940 939 <div id="when.to.use.entity.tags.and.last-modified.dates"> 941 <h2 id="rfc.section.2.4"><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></h2>940 <h2 id="rfc.section.2.4"><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></h2> 942 941 <p id="rfc.section.2.4.p.1">In <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> responses to GET or HEAD, an origin server: 943 942 </p> … … 993 992 of the selected representation. 994 993 </p> 995 <p id="rfc.section.3.1.p.8">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 reflected994 <p id="rfc.section.3.1.p.8">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 996 995 in the current state of the target resource (i.e., the change requested by the user agent has already succeeded, but the user 997 996 agent might not be aware of it, perhaps because the prior response was lost or a compatible change was made by some other … … 1030 1029 selected representation. 1031 1030 </p> 1032 <p id="rfc.section.3.2.p.9">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.1031 <p id="rfc.section.3.2.p.9">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. 1033 1032 </p> 1034 1033 <p id="rfc.section.3.2.p.10">Requirements on cache handling of a received If-None-Match header field are defined in <a href="p6-cache.html#validation.received" title="Handling a Received Validation Request">Section 4.3.2</a> of <a href="#RFC7234" id="rfc.xref.RFC7234.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a>. … … 1045 1044 </pre><p id="rfc.section.3.3.p.3">An example of the field is:</p> 1046 1045 <div id="rfc.figure.u.13"></div><pre class="text"> If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT 1047 </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 the1048 sake of interoperating with older intermediaries that might not implement <a href="#header.if-none-match" class="smpl">If-None-Match</a>.1046 </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 1047 the sake of interoperating with older intermediaries that might not implement <a href="#header.if-none-match" class="smpl">If-None-Match</a>. 1049 1048 </p> 1050 1049 <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 … … 1054 1053 </p> 1055 1054 <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 1056 does not have an entity-tag ; and,2) to limit the scope of a web traversal to resources that have recently changed.1055 does not have an entity-tag and 2) to limit the scope of a web traversal to resources that have recently changed. 1057 1056 </p> 1058 1057 <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 … … 1081 1080 </pre><p id="rfc.section.3.4.p.3">An example of the field is:</p> 1082 1081 <div id="rfc.figure.u.15"></div><pre class="text"> If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT 1083 </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 for1082 </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 1084 1083 the sake of interoperating with older intermediaries that might not implement <a href="#header.if-match" class="smpl">If-Match</a>. 1085 1084 </p> … … 1093 1092 </p> 1094 1093 <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 origin server <em class="bcp14">MUST NOT</em> perform the requested method if the selected representation's last modification date is more recent than the date provided 1095 in the field-value; 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 reflected1094 in the field-value; 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 1096 1095 in the current state of the target resource (i.e., the change requested by the user agent has already succeeded, but the user 1097 1096 agent might not be aware of that because the prior response message was lost or a compatible change was made by some other … … 1105 1104 <div id="header.if-range"> 1106 1105 <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a> <a href="#header.if-range">If-Range</a></h2> 1107 <p id="rfc.section.3.5.p.1">The "If-Range" header field provides a special conditional request mechanism that is similar to the <a href="#header.if-match" class="smpl">If-Match</a> and <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> header 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.1106 <p id="rfc.section.3.5.p.1">The "If-Range" header field provides a special conditional request mechanism that is similar to the <a href="#header.if-match" class="smpl">If-Match</a> and <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> header fields but that 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. 1108 1107 If-Range is defined in <a href="p5-range.html#header.if-range" title="If-Range">Section 3.2</a> of <a href="#RFC7233" id="rfc.xref.RFC7233.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[RFC7233]</cite></a>. 1109 1108 </p> … … 1115 1114 <div id="rfc.iref.21"></div> 1116 1115 <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a> <a href="#status.304">304 Not Modified</a></h2> 1117 <p id="rfc.section.4.1.p.1">The <dfn>304 (Not Modified)</dfn> status code indicates that a conditional GET or HEAD request has been received and would have resulted in a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response if it were not for the fact that the condition hasevaluated to false. In other words, there is no need for the server1116 <p id="rfc.section.4.1.p.1">The <dfn>304 (Not Modified)</dfn> status code indicates that a conditional GET or HEAD request has been received and would have resulted in a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response if it were not for the fact that the condition evaluated to false. In other words, there is no need for the server 1118 1117 to transfer a representation of the target resource because the request indicates that the client, which made the request 1119 1118 conditional, already has a valid representation; the server is therefore redirecting the client to make use of that stored … … 1136 1135 <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 1137 1136 server. This response code allows the client to place preconditions on the current resource state (its current representations 1138 and metadata) and thusprevent the request method from being applied if the target resource is in an unexpected state.1137 and metadata) and, thus, prevent the request method from being applied if the target resource is in an unexpected state. 1139 1138 </p> 1140 1139 </div> … … 1146 1145 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. 1147 1146 </p> 1148 <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 can1147 <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 it <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 1149 1148 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 1150 1149 involve the selection or modification of a <a href="p2-semantics.html#representations" class="smpl">selected representation</a>, such as CONNECT, OPTIONS, or TRACE. -
draft-ietf-httpbis/latest/p4-conditional.xml
r2667 r2671 200 200 (<xref target="header.last-modified"/>) and opaque entity tags 201 201 (<xref target="header.etag"/>). Additional metadata that reflects resource state 202 has been defined by various extensions of HTTP, such as Web DAV203 <xref target="RFC4918"/>, that are beyond the scope of this specification.202 has been defined by various extensions of HTTP, such as Web Distributed 203 Authoring and Versioning (WebDAV, <xref target="RFC4918"/>), that are beyond the scope of this specification. 204 204 A resource metadata value is referred to as a "<x:dfn>validator</x:dfn>" 205 205 when it is used within a precondition. … … 260 260 might not change for every change to the representation data. This 261 261 weakness might be due to limitations in how the value is calculated, such 262 as clock resolution oran inability to ensure uniqueness for all possible263 representations of the resource, or due to a desire bythe resource owner262 as clock resolution, an inability to ensure uniqueness for all possible 263 representations of the resource, or a desire of the resource owner 264 264 to group representations by some self-determined set of equivalency 265 265 rather than unique sequences of data. An origin server &SHOULD; change a … … 406 406 have a <x:ref>Date</x:ref> value equal to its Last-Modified time. The 407 407 arbitrary 60-second limit guards against the possibility that the Date and 408 Last-Modified values are generated from different clocks ,or at somewhat408 Last-Modified values are generated from different clocks or at somewhat 409 409 different times during the preparation of the response. An 410 410 implementation &MAY; use a value larger than 60 seconds, if it is … … 444 444 <t> 445 445 &Note; Previously, opaque-tag was defined to be a quoted-string 446 (<xref target="RFC2616" x:fmt="," x:sec="3.11"/>) , thussome recipients446 (<xref target="RFC2616" x:fmt="," x:sec="3.11"/>); thus, some recipients 447 447 might perform backslash unescaping. Servers therefore ought to avoid 448 448 backslash characters in entity tags. … … 492 492 </t> 493 493 <t> 494 An origin server &SHOULD; send ETag for any selected representation494 An origin server &SHOULD; send an ETag for any selected representation 495 495 for which detection of changes can be reasonably and consistently 496 496 determined, since the entity-tag's use in conditional requests and … … 506 506 <x:anchor-alias value="weak comparison"/> 507 507 <t> 508 There are two entity-tag comparison functions, depending 509 on whether the comparison context allows the use of weak validators 510 or not: 508 There are two entity-tag comparison functions, depending on whether or not 509 the comparison context allows the use of weak validators: 511 510 <list style="symbols"> 512 511 <t><x:dfn>Strong comparison</x:dfn>: two entity-tags are equivalent if both … … 518 517 </t> 519 518 <t> 520 The example below shows the results for a set of entity-tag pairs ,521 and boththe weak and strong comparison function results:519 The example below shows the results for a set of entity-tag pairs and both 520 the weak and strong comparison function results: 522 521 </t> 523 522 <texttable align="left"> … … 549 548 </section> 550 549 551 <section title="Example: Entity- tags Varying on Content-Negotiated Resources" anchor="example.entity.tag.vs.conneg">550 <section title="Example: Entity-Tags Varying on Content-Negotiated Resources" anchor="example.entity.tag.vs.conneg"> 552 551 <t> 553 552 Consider a resource that is subject to content negotiation … … 606 605 </section> 607 606 608 <section title="When to Use Entity- tags and Last-Modified Dates" anchor="when.to.use.entity.tags.and.last-modified.dates">607 <section title="When to Use Entity-Tags and Last-Modified Dates" anchor="when.to.use.entity.tags.and.last-modified.dates"> 609 608 <t> 610 609 In <x:ref>200 (OK)</x:ref> responses to GET or HEAD, an origin server: … … 707 706 <t> 708 707 An origin server &MUST-NOT; perform the requested method if a received 709 If-Match condition evaluates to false; instead the origin server &MUST;710 respond with either :711 a) the <x:ref>412 (Precondition Failed)</x:ref> status code ; or,708 If-Match condition evaluates to false; instead, the origin server &MUST; 709 respond with either 710 a) the <x:ref>412 (Precondition Failed)</x:ref> status code or 712 711 b) one of the <x:ref>2xx (Successful)</x:ref> status codes if the origin 713 712 server has verified that a state change is being requested and the final … … 787 786 evaluates to false; instead, the origin server &MUST; respond with either 788 787 a) the <x:ref>304 (Not Modified)</x:ref> status code if the request method 789 is GET or HEAD; or, 790 b) the <x:ref>412 (Precondition Failed)</x:ref> status code for all other 791 request methods. 788 is GET or HEAD or b) the <x:ref>412 (Precondition Failed)</x:ref> status 789 code for all other request methods. 792 790 </t> 793 791 <t> … … 819 817 <x:ref>If-None-Match</x:ref> header field; the condition in 820 818 <x:ref>If-None-Match</x:ref> is considered to be a more accurate 821 replacement for the condition in If-Modified-Since and the two are only819 replacement for the condition in If-Modified-Since, and the two are only 822 820 combined for the sake of interoperating with older intermediaries that 823 821 might not implement <x:ref>If-None-Match</x:ref>. … … 835 833 If-Modified-Since is typically used for two distinct purposes: 836 834 1) to allow efficient updates of a cached representation that does not 837 have an entity-tag; and, 838 2) to limit the scope of a web traversal to resources that have recently 839 changed. 835 have an entity-tag and 2) to limit the scope of a web traversal to resources 836 that have recently changed. 840 837 </t> 841 838 <t> … … 901 898 <x:ref>If-Match</x:ref> header field; the condition in 902 899 <x:ref>If-Match</x:ref> is considered to be a more accurate replacement for 903 the condition in If-Unmodified-Since and the two are only combined for the900 the condition in If-Unmodified-Since, and the two are only combined for the 904 901 sake of interoperating with older intermediaries that might not implement 905 902 <x:ref>If-Match</x:ref>. … … 928 925 The origin server &MUST-NOT; perform the requested method if the selected 929 926 representation's last modification date is more recent than the date 930 provided in the field-value; instead the 931 origin server &MUST; respond with either: 932 a) the <x:ref>412 (Precondition Failed)</x:ref> status code; or, 927 provided in the field-value; instead the origin server &MUST; respond with either 928 a) the <x:ref>412 (Precondition Failed)</x:ref> status code or 933 929 b) one of the <x:ref>2xx (Successful)</x:ref> status codes if the origin 934 930 server has verified that a state change is being requested and the final … … 951 947 The "If-Range" header field provides a special conditional request 952 948 mechanism that is similar to the <x:ref>If-Match</x:ref> and 953 <x:ref>If-Unmodified-Since</x:ref> header fields but instructs the949 <x:ref>If-Unmodified-Since</x:ref> header fields but that instructs the 954 950 recipient to ignore the <x:ref>Range</x:ref> header field if the validator 955 951 doesn't match, resulting in transfer of the new selected representation … … 968 964 conditional GET or HEAD request has been 969 965 received and would have resulted in a <x:ref>200 (OK)</x:ref> response 970 if it were not for the fact that the condition hasevaluated to false.966 if it were not for the fact that the condition evaluated to false. 971 967 In other words, there is no need for the server to transfer a 972 968 representation of the target resource because the request indicates that … … 1016 1012 when tested on the server. This response code allows the client to place 1017 1013 preconditions on the current resource state (its current representations 1018 and metadata) and thusprevent the request method from being applied if the1014 and metadata) and, thus, prevent the request method from being applied if the 1019 1015 target resource is in an unexpected state. 1020 1016 </t> … … 1037 1033 A server that is not the origin server for the target resource and cannot 1038 1034 act as a cache for requests on the target resource &MUST-NOT; evaluate the 1039 conditional request header fields defined by this specification, and 1035 conditional request header fields defined by this specification, and it 1040 1036 &MUST; forward them if the request is forwarded, since the generating 1041 1037 client intends that they be evaluated by a server that can provide a
Note: See TracChangeset
for help on using the changeset viewer.