Changeset 868 for draft-ietf-httpbis/latest/p4-conditional.html
- Timestamp:
- 22/07/10 09:10:39 (12 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p4-conditional.html
r863 r868 704 704 <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="status.412" href="#status.412">412 Precondition Failed</a></h2> 705 705 <p id="rfc.section.3.2.p.1">The precondition given in one or more of the request-header fields evaluated to false when it was tested on the server. This 706 response code allows the client to place preconditions on the current resource meta information (header field data) and thus707 preventthe requested method from being applied to a resource other than the one intended.706 response code allows the client to place preconditions on the current resource metadata (header field data) and thus prevent 707 the requested method from being applied to a resource other than the one intended. 708 708 </p> 709 709 <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="weak.and.strong.validators" href="#weak.and.strong.validators">Weak and Strong Validators</a></h1> 710 <p id="rfc.section.4.p.1">Since both origin servers and caches will compare two validators to decide if they represent the same or different entities, 711 one normally would expect that if the entity (the entity-body or any entity-headers) changes in any way, then the associated 712 validator would change as well. If this is true, then we call this validator a "strong validator." 710 <p id="rfc.section.4.p.1">Since both origin servers and caches will compare two validators to decide if they represent the same or different representations, 711 one normally would expect that if the representation (including both representation header fields and representation body) 712 changes in any way, then the associated validator would change as well. If this is true, then we call this validator a "strong 713 validator." 713 714 </p> 714 715 <p id="rfc.section.4.p.2">However, there might be cases when a server prefers to change the validator only on semantically significant changes, and 715 not when insignificant aspects of the entity change. A validator that does not always change when the resource changes is716 a "weak validator."716 not when insignificant aspects of the representation change. A validator that does not always change when the representation 717 changes is a "weak validator." 717 718 </p> 718 719 <p id="rfc.section.4.p.3">Entity tags are normally "strong validators," but the protocol provides a mechanism to tag an entity tag as "weak." One can 719 think of a strong validator as one that changes whenever the bits of an entity changes, while a weak value changes whenever 720 the meaning of an entity changes. Alternatively, one can think of a strong validator as part of an identifier for a specific 721 entity, while a weak validator is part of an identifier for a set of semantically equivalent entities. 720 think of a strong validator as one that changes whenever the sequence of bits in a representation changes, while a weak value 721 changes whenever the meaning of a representation changes. Alternatively, one can think of a strong validator as part of an 722 identifier for a specific representation, whereas a weak validator is part of an identifier for a set of semantically equivalent 723 representations. 722 724 </p> 723 725 <ul class="empty"> 724 <li> <b>Note:</b> One example of a strong validator is an integer that is incremented in stable storage every time a n entityis changed.725 </li> 726 <li>An entity's modification time, if represented withone-second resolution, could be a weak validator, since it is possible727 that the re sourcemight be modified twice during a single second.726 <li> <b>Note:</b> One example of a strong validator is an integer that is incremented in stable storage every time a representation is changed. 727 </li> 728 <li>An entity's modification time, if defined with only one-second resolution, could be a weak validator, since it is possible 729 that the representation might be modified twice during a single second. 728 730 </li> 729 731 <li>Support for weak validators is optional. However, weak validators allow for more efficient caching of equivalent objects; … … 736 738 </p> 737 739 <p id="rfc.section.4.p.5">Strong validators are usable in any context. Weak validators are only usable in contexts that do not depend on exact equality 738 of a n entity. For example, either kind is usable for a conditional GET of a full entity. However, only a strong validator739 is usable for a sub-range retrieval, since otherwise the client might end up with an internally inconsistent entity.740 of a representation. For example, either kind is usable for a normal conditional GET. However, only a strong validator is 741 usable for a sub-range retrieval, since otherwise the client might end up with an internally inconsistent representation. 740 742 </p> 741 743 <p id="rfc.section.4.p.6">Clients <em class="bcp14">MUST NOT</em> use weak validators in range requests (<a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>). … … 795 797 </p> 796 798 <ul> 797 <li>The validator is being compared by an origin server to the actual current validator for the entityand,</li>798 <li>That origin server reliably knows that the associated entity did not change twice during the second covered by the presented799 validator.799 <li>The validator is being compared by an origin server to the actual current validator for the representation and,</li> 800 <li>That origin server reliably knows that the associated representation did not change twice during the second covered by the 801 presented validator. 800 802 </li> 801 803 </ul> … … 803 805 <ul> 804 806 <li>The validator is about to be used by a client in an If-Modified-Since or If-Unmodified-Since header, because the client has 805 a cache entry for the associated entity, and807 a cache entry for the associated representation, and 806 808 </li> 807 809 <li>That cache entry includes a Date value, which gives the time when the origin server sent the original response, and</li> … … 810 812 <p id="rfc.section.4.p.12">or </p> 811 813 <ul> 812 <li>The validator is being compared by an intermediate cache to the validator stored in its cache entry for the entity, and</li> 814 <li>The validator is being compared by an intermediate cache to the validator stored in its cache entry for the representation, 815 and 816 </li> 813 817 <li>That cache entry includes a Date value, which gives the time when the origin server sent the original response, and</li> 814 818 <li>The presented Last-Modified time is at least 60 seconds before the Date value.</li> … … 892 896 <p id="rfc.section.6.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to conditional requests.</p> 893 897 <p id="rfc.section.6.p.2">For entity-header fields, both sender and recipient refer to either the client or the server, depending on who sends and who 894 receives the entity.898 receives the message. 895 899 </p> 896 900 <div id="rfc.iref.e.1"></div> … … 929 933 <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.6"></span><span id="rfc.iref.g.7"></span> <a href="#header.if-match" class="smpl">If-Match</a> = "If-Match" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.if-match" class="smpl">If-Match-v</a> 930 934 <a href="#header.if-match" class="smpl">If-Match-v</a> = "*" / 1#<a href="#entity.tags" class="smpl">entity-tag</a> 931 </pre><p id="rfc.section.6.2.p.4">If any of the entity tags match the entity tag of the entity that would have been returned in the response to a similar GET932 request (without the If-Match header) on that resource, or if "*" is given and any current entity exists for that resource,935 </pre><p id="rfc.section.6.2.p.4">If any of the entity tags match the entity tag of the representation that would have been returned in the response to a similar 936 GET request (without the If-Match header) on that resource, or if "*" is given and any current entity exists for that resource, 933 937 then the server <em class="bcp14">MAY</em> perform the requested method as if the If-Match header field did not exist. 934 938 </p> 935 <p id="rfc.section.6.2.p.5">If none of the entity tags match, or if "*" is given and no current entityexists, the server <em class="bcp14">MUST NOT</em> perform the requested method, and <em class="bcp14">MUST</em> return a 412 (Precondition Failed) response. This behavior is most useful when the client wants to prevent an updating method,939 <p id="rfc.section.6.2.p.5">If none of the entity tags match, or if "*" is given and no current representation exists, the server <em class="bcp14">MUST NOT</em> perform the requested method, and <em class="bcp14">MUST</em> return a 412 (Precondition Failed) response. This behavior is most useful when the client wants to prevent an updating method, 936 940 such as PUT, from modifying a resource that has changed since the client last retrieved it. 937 941 </p> … … 941 945 <p id="rfc.section.6.2.p.7">The meaning of "If-Match: *" is that the method <em class="bcp14">SHOULD</em> be performed if the representation selected by the origin server (or by a cache, possibly using the Vary mechanism, see <a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) exists, and <em class="bcp14">MUST NOT</em> be performed if the representation does not exist. 942 946 </p> 943 <p id="rfc.section.6.2.p.8">A request intended to update a resource (e.g., a PUT) <em class="bcp14">MAY</em> include an If-Match header field to signal that the request method <em class="bcp14">MUST NOT</em> be applied if the entity corresponding to the If-Match value (a single entity tag) is no longer a representation of that resource.944 This allows the user to indicate that they do not wish the request to be successful if the resource has been changed without945 their knowledge. Examples:947 <p id="rfc.section.6.2.p.8">A request intended to update a resource (e.g., a PUT) <em class="bcp14">MAY</em> include an If-Match header field to signal that the request method <em class="bcp14">MUST NOT</em> be applied if the representation corresponding to the If-Match value (a single entity tag) is no longer a representation of 948 that resource. This allows the user to indicate that they do not wish the request to be successful if the resource has been 949 changed without their knowledge. Examples: 946 950 </p> 947 951 <div id="rfc.figure.u.10"></div><pre class="text"> If-Match: "xyzzy" … … 1014 1018 <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.10"></span><span id="rfc.iref.g.11"></span> <a href="#header.if-none-match" class="smpl">If-None-Match</a> = "If-None-Match" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.if-none-match" class="smpl">If-None-Match-v</a> 1015 1019 <a href="#header.if-none-match" class="smpl">If-None-Match-v</a> = "*" / 1#<a href="#entity.tags" class="smpl">entity-tag</a> 1016 </pre><p id="rfc.section.6.4.p.5">If any of the entity tags match the entity tag of the entity that would have been returned in the response to a similar GET1017 request (without the If-None-Match header) on that resource, or if "*" is given and any current entity exists for that resource,1018 then the server <em class="bcp14">MUST NOT</em> perform the requested method, unless required to do so because the resource's modification date fails to match that supplied1019 in an If-Modified-Since header field in the request. Instead, if the request method was GET or HEAD, the server <em class="bcp14">SHOULD</em> respond with a 304 (Not Modified) response, including the cache-related header fields (particularly ETag) of one of the entities1020 </pre><p id="rfc.section.6.4.p.5">If any of the entity tags match the entity tag of the representation that would have been returned in the response to a similar 1021 GET request (without the If-None-Match header) on that resource, or if "*" is given and any current representation exists 1022 for that resource, then the server <em class="bcp14">MUST NOT</em> perform the requested method, unless required to do so because the resource's modification date fails to match that supplied 1023 in an If-Modified-Since header field in the request. Instead, if the request method was GET or HEAD, the server <em class="bcp14">SHOULD</em> respond with a 304 (Not Modified) response, including the cache-related header fields (particularly ETag) of one of the representations 1020 1024 that matched. For all other request methods, the server <em class="bcp14">MUST</em> respond with a status of 412 (Precondition Failed). 1021 1025 </p> … … 1075 1079 last modification would indicate some time in the future, the server <em class="bcp14">MUST</em> replace that date with the message origination date. 1076 1080 </p> 1077 <p id="rfc.section.6.6.p.7">An origin server <em class="bcp14">SHOULD</em> obtain the Last-Modified value of the entity as close as possible to the time that it generates the Date value of its response.1078 This allows a recipient to make an accurate assessment of the entity's modification time, especially if the entity changes1079 near the time that the response is generated.1081 <p id="rfc.section.6.6.p.7">An origin server <em class="bcp14">SHOULD</em> obtain the Last-Modified value of the representation as close as possible to the time that it generates the Date value of 1082 its response. This allows a recipient to make an accurate assessment of the entity's modification time, especially if the 1083 representation changes near the time that the response is generated. 1080 1084 </p> 1081 1085 <p id="rfc.section.6.6.p.8">HTTP/1.1 servers <em class="bcp14">SHOULD</em> send Last-Modified whenever feasible.
Note: See TracChangeset
for help on using the changeset viewer.