Ignore:
Timestamp:
Jul 8, 2012, 7:50:41 AM (7 years ago)
Author:
julian.reschke@…
Message:

Work-in-progress: hyperlink header field definitions(P4)

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p6-cache.xml

    r1738 r1739  
    284284   <x:dfn>validator</x:dfn>
    285285   <list>
    286       <t>A protocol element (e.g., an entity-tag or a Last-Modified time) that
    287       is used to find out whether a stored response is an equivalent copy of
    288       a representation. See &weak-and-strong;.</t>
     286      <t>A protocol element (e.g., an entity-tag or a <x:ref>Last-Modified</x:ref>
     287      time) that is used to find out whether a stored response is an equivalent
     288      copy of a representation. See &weak-and-strong;.</t>
    289289   </list>
    290290</t>
     
    297297         current value will change if the representation body changes; i.e.,
    298298         an entity-tag that is not marked as weak (&entity-tags;) or,
    299          if no entity-tag is provided, a Last-Modified value that is strong
    300          in the sense defined by &lastmod-comparison;.</t>
     299         if no entity-tag is provided, a <x:ref>Last-Modified</x:ref> value
     300         that is strong in the sense defined by &lastmod-comparison;.</t>
    301301   </list>
    302302</t>
     
    619619   a cache &MAY; assign a heuristic expiration time when an explicit time is not
    620620   specified, employing algorithms that use other header field values (such as the
    621    Last-Modified time) to estimate a plausible expiration time. This
    622    specification does not provide specific algorithms, but does impose
     621   <x:ref>Last-Modified</x:ref> time) to estimate a plausible expiration time.
     622   This specification does not provide specific algorithms, but does impose
    623623   worst-case constraints on their results.
    624624</t>
     
    697697</t>
    698698<t>
    699    Also, if the response has a Last-Modified header field
     699   Also, if the response has a <x:ref>Last-Modified</x:ref> header field
    700700   (&header-last-modified;), caches are encouraged to use a heuristic
    701701   expiration value that is no more than some fraction of the interval since
     
    896896</t>
    897897<t>
    898    When sending such a conditional request, a cache adds an If-Modified-Since
    899    header field whose value is that of the Last-Modified header field from the
    900    selected (see <xref target="caching.negotiated.responses"/>) stored
    901    response, if available.
    902 </t>
    903 <t>
    904    Additionally, a cache can add an If-None-Match header field whose value is
    905    that of the ETag header field(s) from all responses stored for the
    906    requested URI, if present. However, if any of the stored responses contains
    907    only partial content, the cache shouldn't include its entity-tag in the
    908    If-None-Match header field unless the request is for a range that would be
    909    fully satisfied by that stored response.
     898   When sending such a conditional request, a cache adds an
     899   <x:ref>If-Modified-Since</x:ref> header field whose value is that of the
     900   <x:ref>Last-Modified</x:ref> header field from the selected
     901   (see <xref target="caching.negotiated.responses"/>) stored response, if
     902   available.
     903</t>
     904<t>
     905   Additionally, a cache can add an <x:ref>If-None-Match</x:ref> header field
     906   whose value is that of the <x:ref>ETag</x:ref> header field(s) from all
     907   responses stored for the requested URI, if present. However, if any of the
     908   stored responses contains only partial content, the cache shouldn't
     909   include its entity-tag in the If-None-Match header field unless the request
     910   is for a range that would be fully satisfied by that stored response.
    910911</t>
    911912
     
    989990   If one or more stored GET responses can be selected (as per <xref
    990991   target="caching.negotiated.responses"/>) for a HEAD request, and the
    991    Content-Length, ETag or Last-Modified value of a HEAD response differs from
    992    that in a selected GET response, the cache &MUST; consider that selected
    993    response to be stale.
    994 </t>
    995 <t>
    996    If the Content-Length, ETag and Last-Modified values of a HEAD response
    997    (when present) are the same as that in a selected GET response (as per
    998    <xref target="caching.negotiated.responses"/>), the cache &SHOULD; update the
    999    remaining headers in the stored response using the following rules:
     992   Content-Length, <x:ref>ETag</x:ref> or <x:ref>Last-Modified</x:ref> value of
     993   a HEAD response differs from that in a selected GET response, the cache
     994   &MUST; consider that selected response to be stale.
     995</t>
     996<t>
     997   If the Content-Length, <x:ref>ETag</x:ref> and <x:ref>Last-Modified</x:ref>
     998   values of a HEAD response (when present) are the same as that in a selected
     999   GET response (as per <xref target="caching.negotiated.responses"/>), the
     1000   cache &SHOULD; update the remaining headers in the stored response using the
     1001   following rules:
    10001002   <list style="symbols">
    10011003      <t>delete any <x:ref>Warning</x:ref> header fields in the stored response
     
    23312333      <x:defines>304</x:defines>
    23322334      <x:defines>304 (Not Modified)</x:defines>
     2335      <x:defines>ETag</x:defines>
     2336      <x:defines>If-Modified-Since</x:defines>
     2337      <x:defines>If-None-Match</x:defines>
     2338      <x:defines>Last-Modified</x:defines>
    23332339    </x:source>
    23342340  </reference>
Note: See TracChangeset for help on using the changeset viewer.