Changeset 2128 for draft-ietf-httpbis/latest/p4-conditional.xml
- Timestamp:
- 19/01/13 13:53:26 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p4-conditional.xml
r2105 r2128 209 209 </t> 210 210 <t> 211 A "strong validator" is a representation metadata value that &MUST; be211 A "strong validator" is a representation metadata value that is 212 212 changed to a new, previously unused or guaranteed unique, value whenever 213 213 a change occurs to the representation data such that a change would be … … 215 215 </t> 216 216 <t> 217 A strong validator &MAY; be changedfor other reasons, such as when a semantically217 A strong validator might change for other reasons, such as when a semantically 218 218 significant part of the representation metadata is changed (e.g., 219 219 <x:ref>Content-Type</x:ref>), but it is in the best interests of the origin 220 220 server to only change the value when it is necessary to invalidate the 221 221 stored responses held by remote caches and authoring tools. A strong 222 validator &MUST; beunique across all representations of a given resource,222 validator is unique across all representations of a given resource, 223 223 such that no two representations of that resource share the same validator 224 224 unless their payload body would be identical. … … 228 228 of expiration times. Thus, a cache might attempt to validate an 229 229 entry using a validator that it obtained in the distant past. 230 A strong validator &MUST; beunique across all versions of all230 A strong validator is unique across all versions of all 231 231 representations associated with a particular resource over time. 232 232 However, there is no implication of uniqueness across representations … … 453 453 for a representation and the generation of that entity-tag does not satisfy 454 454 the requirements for a strong validator 455 (<xref target="weak.and.strong.validators"/>), then th at456 entity-tag &MUST; be markedas weak by prefixing its opaque value455 (<xref target="weak.and.strong.validators"/>), then the origin server 456 &MUST; mark the entity-tag as weak by prefixing its opaque value 457 457 with "W/" (case-sensitive). 458 458 </t> … … 489 489 <section title="Comparison" anchor="entity.tag.comparison"> 490 490 <x:anchor-alias value="validator.comparison"/> 491 <x:anchor-alias value="strong comparison"/> 492 <x:anchor-alias value="weak comparison"/> 491 493 <t> 492 494 There are two entity-tag comparison functions, depending … … 494 496 or not: 495 497 <list style="symbols"> 496 <t>The strong comparison function: in order to be considered equal, 497 both opaque-tags &MUST; be identical character-by-character, and both 498 &MUST-NOT; be weak.</t> 499 <t>The weak comparison function: in order to be considered equal, both 500 opaque-tags &MUST; be identical character-by-character, but 501 either or both of them &MAY; be tagged as "weak" without affecting 502 the result.</t> 498 <t><x:dfn>Strong comparison</x:dfn>: two entity-tags are equivalent if both 499 are not weak and their opaque-tags match character-by-character.</t> 500 <t><x:dfn>Weak comparison</x:dfn>: two entity-tags are equivalent if their opaque-tags 501 match character-by-character, regardless of either or both 502 being tagged as "weak".</t> 503 503 </list> 504 504 </t> … … 591 591 </section> 592 592 593 <section title=" Rules for When to Use Entity-tags and Last-Modified Dates" anchor="rules.for.when.to.use.entity.tags.and.last-modified.dates">593 <section title="When to Use Entity-tags and Last-Modified Dates" anchor="when.to.use.entity.tags.and.last-modified.dates"> 594 594 <t> 595 595 We adopt a set of rules and recommendations for origin servers, … … 598 598 </t> 599 599 <t> 600 HTTP/1.1 origin servers:600 In <x:ref>200 (OK)</x:ref> responses to GET or HEAD, an origin server: 601 601 <list style="symbols"> 602 602 <t>&SHOULD; send an entity-tag validator unless it is not feasible to … … 612 612 </t> 613 613 <t> 614 In other words, the preferred behavior for an HTTP/1.1 origin server 615 is to send both a strong entity-tag and a <x:ref>Last-Modified</x:ref> value. 616 </t> 617 <t> 618 HTTP/1.1 clients: 614 In other words, the preferred behavior for an origin server 615 is to send both a strong entity-tag and a <x:ref>Last-Modified</x:ref> 616 value in successful responses to a retrieval request. 617 </t> 618 <t> 619 A client: 619 620 <list style="symbols"> 620 621 <t>&MUST; use that entity-tag in any cache-conditional request (using … … 638 639 </list> 639 640 </t> 640 <t>641 An HTTP/1.1 origin server, upon receiving a conditional request that642 includes both a Last-Modified date (e.g., in an <x:ref>If-Modified-Since</x:ref>643 or <x:ref>If-Unmodified-Since</x:ref> header field) and one or more644 entity-tags (e.g., in an <x:ref>If-Match</x:ref>, <x:ref>If-None-Match</x:ref>,645 or <x:ref>If-Range</x:ref> header field) as cache validators, &MUST-NOT;646 send a response status code of <x:ref>304 (Not Modified)</x:ref> unless647 doing so is consistent with all of the conditional header fields in the648 request.649 </t>650 <t>651 An HTTP/1.1 caching proxy, upon receiving a conditional request that652 includes both a Last-Modified date and one or more entity-tags as653 cache validators, &MUST-NOT; send a locally cached response to the654 client unless that cached response is consistent with all of the655 conditional header fields in the request.656 <list><t>657 &Note; The general principle behind these rules is that HTTP/1.1658 servers and clients ought to transmit as much non-redundant659 information as is available in their responses and requests.660 HTTP/1.1 systems receiving this information will make the most661 conservative assumptions about the validators they receive.662 </t><t>663 HTTP/1.0 clients and caches might ignore entity-tags. Generally,664 last-modified values received or used by these systems will665 support transparent and efficient caching, and so HTTP/1.1 origin666 servers still ought to provide Last-Modified values.667 </t></list>668 </t>669 641 </section> 670 642 </section> … … 674 646 This section defines the syntax and semantics of HTTP/1.1 header fields 675 647 for applying preconditions on requests. 676 <xref target="precedence"/> defines the order of evaluation when677 more than one precondition is present in a request.648 <xref target="precedence"/> defines when the preconditions are applied and 649 the order of evaluation when more than one precondition is present. 678 650 </t> 679 651 … … 705 677 </t> 706 678 <t> 707 If the condition is met, the server &MAY; perform the request method as if 708 the If-Match header field was not present. 679 If the condition is met, the server &MAY; perform the request method. 709 680 </t> 710 681 <t> … … 717 688 &MUST-NOT; perform the requested method if the condition is not met; 718 689 instead, they &MUST; forward the request towards the origin server. 719 </t>720 <t>721 If the request would, without the If-Match header field, result in722 anything other than a <x:ref>2xx (Successful)</x:ref> or <x:ref>412 (Precondition Failed)</x:ref>723 status code, then the If-Match header field &MUST; be ignored.724 690 </t> 725 691 <t> … … 775 741 selected representation that has a matching entity-tag. For all other 776 742 request methods, the server &MUST; respond with a <x:ref>412 (Precondition 777 Failed)</x:ref> status code. 778 </t> 779 <t> 780 If the condition is met, the server &MAY; perform the requested method 781 as if the If-None-Match header field did not exist, but &MUST; also ignore 782 any <x:ref>If-Modified-Since</x:ref> header field(s) in the request. That 783 is, if no entity-tags match, then the server &MUST-NOT; send a <x:ref>304 784 (Not Modified)</x:ref> response. 785 </t> 786 <t> 787 If the request would, without the If-None-Match header field, result 788 in anything other than a <x:ref>2xx (Successful)</x:ref> or 789 <x:ref>304 (Not Modified)</x:ref> status code, then the If-None-Match 790 header field &MUST; be ignored. (See <xref 791 target="rules.for.when.to.use.entity.tags.and.last-modified.dates"/> for 792 a discussion of server behavior when both <x:ref>If-Modified-Since</x:ref> 793 and If-None-Match appear in the same request.) 743 Failed)</x:ref> status code when the condition is not met. 744 </t> 745 <t> 746 If the condition is met, the server &MAY; perform the requested method and 747 &MUST; ignore any <x:ref>If-Modified-Since</x:ref> header field(s) in the 748 request. That is, if no entity-tags match, then the server &MUST-NOT; send 749 a <x:ref>304 (Not Modified)</x:ref> response. 794 750 </t> 795 751 <t> … … 897 853 respond with the <x:ref>412 (Precondition Failed)</x:ref> status code. 898 854 If the selected representation has not been modified since the time 899 specified in this field, the server &SHOULD; perform the request 900 method as if the If-Unmodified-Since header field were not present. 855 specified in this field, the server &MAY; perform the request. 901 856 </t> 902 857 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-Unmodified-Since"/> … … 910 865 </artwork></figure> 911 866 <t> 912 If a request normally (i.e., in absence of the If-Unmodified-Since 913 header field) would result in anything other than a <x:ref>2xx (Successful)</x:ref> 914 or <x:ref>412 (Precondition Failed)</x:ref> status code, 915 the If-Unmodified-Since header field &SHOULD; be ignored. 916 </t> 917 <t> 918 If the specified date is invalid, the header field &MUST; be ignored. 867 A server &MUST; ignore the If-Unmodified-Since header field if the 868 received value is not a valid HTTP-date. 919 869 </t> 920 870 </section> … … 982 932 <x:anchor-alias value="412 (Precondition Failed)"/> 983 933 <t> 984 The <x:dfn>412 (Precondition Failed)</x:dfn> status code indicates that one or more preconditions given in 985 the request header fields evaluated to false when tested on the server. 986 This response code allows the client to place preconditions on the 987 current resource state (its current representations and metadata) 988 and thus prevent the request method from being applied if the target 989 resource is in an unexpected state. 990 </t> 991 </section> 992 </section> 993 994 <section title="Precedence" anchor="precedence"> 934 The <x:dfn>412 (Precondition Failed)</x:dfn> status code indicates that one 935 or more preconditions given in the request header fields evaluated to false 936 when tested on the server. This response code allows the client to place 937 preconditions on the current resource state (its current representations 938 and metadata) and thus prevent the request method from being applied if the 939 target resource is in an unexpected state. 940 </t> 941 </section> 942 </section> 943 944 <section title="Evaluation and Precedence" anchor="precedence"> 945 <t> 946 For each conditional request, a server &MUST; evaluate the request 947 preconditions after it has successfully performed its normal request checks 948 (i.e., just before it would perform the action associated with the request 949 method). Preconditions are ignored if the server determines that an error 950 or redirect response applies before they are evaluated. 951 </t> 995 952 <t> 996 953 When more than one conditional request header field is present in a request, … … 999 956 single, logical order, due to the fact that entity tags are presumed to be 1000 957 more accurate than date validators. For example, the only reason to send 1001 both <x:ref>If-Modified-Since</x:ref> and <x:ref>If-None-Match</x:ref> in the same GET request is to 1002 support intermediary caches that might not have implemented <x:ref>If-None-Match</x:ref>, 1003 so it makes sense to ignore the <x:ref>If-Modified-Since</x:ref> when entity tags are 1004 understood and available for the selected representation. 958 both <x:ref>If-Modified-Since</x:ref> and <x:ref>If-None-Match</x:ref> in 959 the same GET request is to support intermediary caches that might not have 960 implemented <x:ref>If-None-Match</x:ref>, so it makes sense to ignore the 961 <x:ref>If-Modified-Since</x:ref> when entity tags are understood and 962 available for the selected representation. 1005 963 </t> 1006 964 <t>
Note: See TracChangeset
for help on using the changeset viewer.