Ignore:
Timestamp:
08/07/12 18:15:03 (8 years ago)
Author:
julian.reschke@…
Message:

Work-in-progress: hyperlink header field definitions, plus minor editorial improvements (P2)

File:
1 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p4-conditional.html

    r1739 r1740  
    661661         mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require
    662662         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 type
    664          of error recovery could 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.
    665665      </p>
    666666      <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a id="notation" href="#notation">Syntax Notation</a></h2>
    … …  
    691691      </p>
    692692      <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
    696697         validator unless their payload body would be identical.
    697698      </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 validate
     699      <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
    699700         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
    700701         implication of uniqueness across representations of different resources (i.e., the same strong validator might be in use for
    701702         representations of multiple resources at the same time and does not imply that those representations are equivalent).
    702703      </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 change
     704      <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
    704705         to a representation always results in a unique node name and revision identifier being assigned before the representation
    705706         is made accessible to GET. A cryptographic hash function applied to the representation data is also sufficient if the data
    … …  
    708709         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.
    709710      </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 representation
     711      <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
    711712         data. This weakness might be due to limitations in how the value is calculated, such as clock resolution or an inability to
    712713         ensure uniqueness for all possible representations of the resource, or due to a desire by the resource owner to group representations
    … …  
    714715         In other words, a weak entity-tag ought to change whenever the origin server wants caches to invalidate old responses.
    715716      </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, might
     717      <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
    717718         be grouped into sets of equivalent representations (from the origin server's perspective) with the same weak validator in
    718719         order to allow cached representations to be valid for a reasonable period of time (perhaps adjusted dynamically based on server
    … …  
    721722         those modifications.
    722723      </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 when
     724      <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
    724725         a server compares two validators. Weak validators are only usable in contexts that do not depend on exact equality of a representation's
    725726         payload body. Strong validators are usable and preferred for all conditional requests, including cache validation, partial
    … …  
    745746         use its value to make conditional requests and test the validity of locally cached responses.
    746747      </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
    754753         on cache validation.
    755754      </p>
    … …  
    771770         <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
    772771         </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>
    774774         <li>The presented Last-Modified time is at least 60 seconds before the Date value.</li>
    775775      </ul>
    … …  
    779779            and
    780780         </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>
    782783         <li>The presented Last-Modified time is at least 60 seconds before the Date value.</li>
    783784      </ul>
    784785      <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.
    788788      </p>
    789789      <div id="rfc.iref.e.1"></div>
    … …  
    883883      </div>
    884884      <h3 id="rfc.section.2.3.3"><a href="#rfc.section.2.3.3">2.3.3</a>&nbsp;<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-Encoding 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>):
     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>):
    886886      </p>
    887887      <div id="rfc.figure.u.6"></div>
    … …  
    10911091         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.
    10921092      </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.
    10941095      </p>
    10951096      <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.