Changeset 1740 for draft-ietf-httpbis/latest/p4-conditional.html
- Timestamp:
- 08/07/12 18:15:03 (11 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p4-conditional.html
r1739 r1740 661 661 mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require 662 662 different error handling strategies; for example, a Web browser might wish to transparently recover from a response where 663 the Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type664 of error recoverycould lead to dangerous consequences.663 the <a href="p2-semantics.html#header.location" class="smpl">Location</a> header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of error recovery 664 could lead to dangerous consequences. 665 665 </p> 666 666 <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a> <a id="notation" href="#notation">Syntax Notation</a></h2> … … 691 691 </p> 692 692 <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 693 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. 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., 694 Content-Type), but it is in the best interests of the origin server to only change the value when it is necessary to invalidate 695 the stored 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 693 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. 694 </p> 695 <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 696 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 696 697 validator unless their payload body would be identical. 697 698 </p> 698 <p id="rfc.section.2.1.p. 3">Cache entries might persist for arbitrarily long periods, regardless of expiration times. Thus, a cache might attempt to validate699 <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 699 700 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 700 701 implication of uniqueness across representations of different resources (i.e., the same strong validator might be in use for 701 702 representations of multiple resources at the same time and does not imply that those representations are equivalent). 702 703 </p> 703 <p id="rfc.section.2.1.p. 4">There are a variety of strong validators used in practice. The best are based on strict revision control, wherein each change704 <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 704 705 to a representation always results in a unique node name and revision identifier being assigned before the representation 705 706 is made accessible to GET. A cryptographic hash function applied to the representation data is also sufficient if the data … … 708 709 occur with content negotiation over media types that happen to share the same data format, then the origin server <em class="bcp14">SHOULD</em> incorporate additional information in the validator to distinguish those representations and avoid confusing cache behavior. 709 710 </p> 710 <p id="rfc.section.2.1.p. 5">In contrast, a "weak validator" is a representation metadata value that might not be changed for every change to the representation711 <p id="rfc.section.2.1.p.6">In contrast, a "weak validator" is a representation metadata value that might not be changed for every change to the representation 711 712 data. This weakness might be due to limitations in how the value is calculated, such as clock resolution or an inability to 712 713 ensure uniqueness for all possible representations of the resource, or due to a desire by the resource owner to group representations … … 714 715 In other words, a weak entity-tag ought to change whenever the origin server wants caches to invalidate old responses. 715 716 </p> 716 <p id="rfc.section.2.1.p. 6">For example, the representation of a weather report that changes in content every second, based on dynamic measurements, might717 <p id="rfc.section.2.1.p.7">For example, the representation of a weather report that changes in content every second, based on dynamic measurements, might 717 718 be grouped into sets of equivalent representations (from the origin server's perspective) with the same weak validator in 718 719 order to allow cached representations to be valid for a reasonable period of time (perhaps adjusted dynamically based on server … … 721 722 those modifications. 722 723 </p> 723 <p id="rfc.section.2.1.p. 7">A "use" of a validator occurs when either a client generates a request and includes the validator in a precondition or when724 <p id="rfc.section.2.1.p.8">A "use" of a validator occurs when either a client generates a request and includes the validator in a precondition or when 724 725 a server compares two validators. Weak validators are only usable in contexts that do not depend on exact equality of a representation's 725 726 payload body. Strong validators are usable and preferred for all conditional requests, including cache validation, partial … … 745 746 use its value to make conditional requests and test the validity of locally cached responses. 746 747 </p> 747 <p id="rfc.section.2.2.1.p.3">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 field-value 748 for its response. This allows a recipient to make an accurate assessment of the representation's modification time, especially 749 if the representation changes near the time that the response is generated. 750 </p> 751 <p id="rfc.section.2.2.1.p.4">An origin server with a clock <em class="bcp14">MUST NOT</em> send a Last-Modified date that is later than the server's time of message origination (Date). If the last modification time 752 is derived from implementation-specific metadata that evaluates to some time in the future, according to the origin server's 753 clock, then the origin server <em class="bcp14">MUST</em> replace that value with the message origination date. This prevents a future modification date from having an adverse impact 748 <p id="rfc.section.2.2.1.p.3">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 <a href="p2-semantics.html#header.date" class="smpl">Date</a> field value for its response. This allows a recipient to make an accurate assessment of the representation's modification 749 time, especially if the representation changes near the time that the response is generated. 750 </p> 751 <p id="rfc.section.2.2.1.p.4">An origin server with a clock <em class="bcp14">MUST NOT</em> send a Last-Modified date that is later than the server's time of message origination (<a href="p2-semantics.html#header.date" class="smpl">Date</a>). If the last modification time is derived from implementation-specific metadata that evaluates to some time in the future, 752 according to the origin server's clock, then the origin server <em class="bcp14">MUST</em> replace that value with the message origination date. This prevents a future modification date from having an adverse impact 754 753 on cache validation. 755 754 </p> … … 771 770 <li>The validator is about to be used by a client in an <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a>, <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> header field, because the client has a cache entry, or <a href="p5-range.html#header.if-range" class="smpl">If-Range</a> for the associated representation, and 772 771 </li> 773 <li>That cache entry includes a Date value, which gives the time when the origin server sent the original response, and</li> 772 <li>That cache entry includes a <a href="p2-semantics.html#header.date" class="smpl">Date</a> value, which gives the time when the origin server sent the original response, and 773 </li> 774 774 <li>The presented Last-Modified time is at least 60 seconds before the Date value.</li> 775 775 </ul> … … 779 779 and 780 780 </li> 781 <li>That cache entry includes a Date value, which gives the time when the origin server sent the original response, and</li> 781 <li>That cache entry includes a <a href="p2-semantics.html#header.date" class="smpl">Date</a> value, which gives the time when the origin server sent the original response, and 782 </li> 782 783 <li>The presented Last-Modified time is at least 60 seconds before the Date value.</li> 783 784 </ul> 784 785 <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 785 both had the same Last-Modified time, then at least one of those responses would have a Date value equal to its Last-Modified 786 time. The arbitrary 60-second limit guards against the possibility that the Date and Last-Modified values are generated from 787 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. 786 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 787 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. 788 788 </p> 789 789 <div id="rfc.iref.e.1"></div> … … 883 883 </div> 884 884 <h3 id="rfc.section.2.3.3"><a href="#rfc.section.2.3.3">2.3.3</a> <a id="example.entity.tag.vs.conneg" href="#example.entity.tag.vs.conneg">Example: Entity-tags varying on Content-Negotiated Resources</a></h3> 885 <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 8</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>), and where the representations returned upon a GET request vary based on the Accept-Encodingrequest header field (<a href="p2-semantics.html#header.accept-encoding" title="Accept-Encoding">Section 9.3</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>):885 <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 8</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>), and where the representations returned upon 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 9.3</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>): 886 886 </p> 887 887 <div id="rfc.figure.u.6"></div> … … 1091 1091 as if it were the payload of a 200 response. The 304 response <em class="bcp14">MUST NOT</em> contain a message-body, and thus is always terminated by the first empty line after the header fields. 1092 1092 </p> 1093 <p id="rfc.section.4.1.p.2">A 304 response <em class="bcp14">MUST</em> include a Date header field (<a href="p2-semantics.html#header.date" title="Date">Section 9.10</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) unless the origin server does not have a clock that can provide a reasonable approximation of the current time. If a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to the same request would have included any of the header fields <a href="p6-cache.html#header.cache-control" class="smpl">Cache-Control</a>, Content-Location, <a href="#header.etag" class="smpl">ETag</a>, <a href="p6-cache.html#header.expires" class="smpl">Expires</a>, or <a href="p6-cache.html#header.vary" class="smpl">Vary</a>, then those same header fields <em class="bcp14">MUST</em> be sent in a 304 response. 1093 <p id="rfc.section.4.1.p.2">A 304 response <em class="bcp14">MUST</em> include a <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field (<a href="p2-semantics.html#header.date" title="Date">Section 9.10</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) unless the origin server does not have a clock that can provide a reasonable approximation of the current time. If a <a href="p2-semantics.html#status.200" class="smpl">200 1094 (OK)</a> response to the same request would have included any of the header fields <a href="p6-cache.html#header.cache-control" class="smpl">Cache-Control</a>, <a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a>, <a href="#header.etag" class="smpl">ETag</a>, <a href="p6-cache.html#header.expires" class="smpl">Expires</a>, or <a href="p6-cache.html#header.vary" class="smpl">Vary</a>, then those same header fields <em class="bcp14">MUST</em> be sent in a 304 response. 1094 1095 </p> 1095 1096 <p id="rfc.section.4.1.p.3">Since the goal of a 304 response is to minimize information transfer when the recipient already has one or more cached representations,
Note: See TracChangeset
for help on using the changeset viewer.