Ignore:
Timestamp:
Jul 8, 2012, 11:15:03 AM (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.xml

    r1739 r1740  
    197197   impact on security. This is because different uses of the protocol require
    198198   different error handling strategies; for example, a Web browser might wish to
    199    transparently recover from a response where the Location header field
    200    doesn't parse according to the ABNF, whereby in a systems control protocol
    201    using HTTP, this type of error recovery could lead to dangerous consequences.
     199   transparently recover from a response where the <x:ref>Location</x:ref>
     200   header field doesn't parse according to the ABNF, whereby in a systems
     201   control protocol using HTTP, this type of error recovery could lead to
     202   dangerous consequences.
    202203</t>
    203204</section>
     
    273274   a change occurs to the representation data such that a change would be
    274275   observable in the payload body of a <x:ref>200 (OK)</x:ref> response to GET.
     276</t>
     277<t>   
    275278   A strong validator &MAY; be changed for other reasons, such as when a semantically
    276279   significant part of the representation metadata is changed (e.g.,
    277    Content-Type), but it is in the best interests of the origin server to only
    278    change the value when it is necessary to invalidate the stored responses
    279    held by remote caches and authoring tools.  A strong validator &MUST; be
    280    unique across all representations of a given resource, such that no two
    281    representations of that resource share the same validator unless
    282    their payload body would be identical.
     280   <x:ref>Content-Type</x:ref>), but it is in the best interests of the origin
     281   server to only change the value when it is necessary to invalidate the
     282   stored responses held by remote caches and authoring tools.  A strong
     283   validator &MUST; be unique across all representations of a given resource,
     284   such that no two representations of that resource share the same validator
     285   unless their payload body would be identical.
    283286</t>
    284287<t>
     
    384387<t>
    385388   An origin server &SHOULD; obtain the Last-Modified value of the
    386    representation as close as possible to the time that it generates
    387    the Date field-value for its response. This allows a recipient to
     389   representation as close as possible to the time that it generates the
     390   <x:ref>Date</x:ref> field value for its response. This allows a recipient to
    388391   make an accurate assessment of the representation's modification time,
    389392   especially if the representation changes near the time that the
     
    392395<t>
    393396   An origin server with a clock &MUST-NOT; send a Last-Modified date
    394    that is later than the server's time of message origination (Date).
     397   that is later than the server's time of message origination (<x:ref>Date</x:ref>).
    395398   If the last modification time is derived from implementation-specific
    396399   metadata that evaluates to some time in the future, according to the
     
    426429        a cache entry, or <x:ref>If-Range</x:ref> for the associated
    427430        representation, and</t>
    428      <t>That cache entry includes a Date value, which gives the time
    429         when the origin server sent the original response, and</t>
     431     <t>That cache entry includes a <x:ref>Date</x:ref> value, which gives the
     432        time when the origin server sent the original response, and</t>
    430433     <t>The presented Last-Modified time is at least 60 seconds before
    431434        the Date value.</t>
     
    437440     <t>The validator is being compared by an intermediate cache to the
    438441        validator stored in its cache entry for the representation, and</t>
    439      <t>That cache entry includes a Date value, which gives the time
    440         when the origin server sent the original response, and</t>
     442     <t>That cache entry includes a <x:ref>Date</x:ref> value, which gives the
     443        time when the origin server sent the original response, and</t>
    441444     <t>The presented Last-Modified time is at least 60 seconds before
    442445        the Date value.</t>
     
    447450   sent by the origin server during the same second, but both had the
    448451   same Last-Modified time, then at least one of those responses would
    449    have a Date value equal to its Last-Modified time. The arbitrary 60-second
    450    limit guards against the possibility that the Date and Last-Modified
    451    values are generated from different clocks, or at somewhat
     452   have a <x:ref>Date</x:ref> value equal to its Last-Modified time. The
     453   arbitrary 60-second limit guards against the possibility that the Date and
     454   Last-Modified values are generated from different clocks, or at somewhat
    452455   different times during the preparation of the response. An
    453456   implementation &MAY; use a value larger than 60 seconds, if it is
     
    597600   Consider a resource that is subject to content negotiation (&content-negotiation;),
    598601   and where the representations returned upon a GET request vary based on
    599    the Accept-Encoding request header field (&header-accept-encoding;):
     602   the <x:ref>Accept-Encoding</x:ref> request header field
     603   (&header-accept-encoding;):
    600604</t>
    601605<figure><preamble>>> Request:</preamble><artwork type="message/http; msgtype=&#34;request&#34;"  x:indent-with="  ">
     
    10151019</t>
    10161020<t>
    1017    A 304 response &MUST; include a Date header field (&header-date;)
    1018    unless the origin server does not have a clock that can provide a
    1019    reasonable approximation of the current time.  If a <x:ref>200 (OK)</x:ref>
    1020    response to the same request would have included any of the header fields
    1021    <x:ref>Cache-Control</x:ref>, Content-Location, <x:ref>ETag</x:ref>,
    1022    <x:ref>Expires</x:ref>, or <x:ref>Vary</x:ref>, then those same header
    1023    fields &MUST; be sent in a 304 response.
     1021   A 304 response &MUST; include a <x:ref>Date</x:ref> header field
     1022   (&header-date;) unless the origin server does not have a clock that can
     1023   provide a reasonable approximation of the current time.  If a <x:ref>200
     1024   (OK)</x:ref> response to the same request would have included any of the
     1025   header fields <x:ref>Cache-Control</x:ref>, <x:ref>Content-Location</x:ref>,
     1026   <x:ref>ETag</x:ref>, <x:ref>Expires</x:ref>, or <x:ref>Vary</x:ref>, then
     1027   those same header fields &MUST; be sent in a 304 response.
    10241028</t>
    10251029<t>
     
    12081212    <x:defines>2xx (Successful)</x:defines>
    12091213    <x:defines>200 (OK)</x:defines>
     1214    <x:defines>Accept-Encoding</x:defines>
     1215    <x:defines>Content-Location</x:defines>
     1216    <x:defines>Content-Type</x:defines>
     1217    <x:defines>Date</x:defines>
     1218    <x:defines>Location</x:defines>
    12101219  </x:source>
    12111220</reference>
Note: See TracChangeset for help on using the changeset viewer.