Changeset 1739 for draft-ietf-httpbis/latest/p6-cache.xml

Timestamp:

Jul 8, 2012, 7:50:41 AM (7 years ago)

Author:

julian.reschke@…

Message:

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

File:

• draft-ietf-httpbis/latest/p6-cache.xml (modified) (7 diffs)

draft-ietf-httpbis/latest/p6-cache.xml

@@ -284 +284 @@
    <x:dfn>validator</x:dfn>
    <list>
-      <t>A protocol element (e.g., an entity-tag or a Last-Modified time) that
-      is used to find out whether a stored response is an equivalent copy of
-      a representation. See &weak-and-strong;.</t>
+      <t>A protocol element (e.g., an entity-tag or a <x:ref>Last-Modified</x:ref>
+      time) that is used to find out whether a stored response is an equivalent
+      copy of a representation. See &weak-and-strong;.</t>
    </list>
 </t>
@@ -297 +297 @@
          current value will change if the representation body changes; i.e.,
          an entity-tag that is not marked as weak (&entity-tags;) or,
-         if no entity-tag is provided, a Last-Modified value that is strong
-         in the sense defined by &lastmod-comparison;.</t>
+         if no entity-tag is provided, a <x:ref>Last-Modified</x:ref> value
+         that is strong in the sense defined by &lastmod-comparison;.</t>
    </list>
 </t>
@@ -619 +619 @@
    a cache &MAY; assign a heuristic expiration time when an explicit time is not
    specified, employing algorithms that use other header field values (such as the
-   Last-Modified time) to estimate a plausible expiration time. This
-   specification does not provide specific algorithms, but does impose
+   <x:ref>Last-Modified</x:ref> time) to estimate a plausible expiration time.
+   This specification does not provide specific algorithms, but does impose
    worst-case constraints on their results.
 </t>
@@ -697 +697 @@
 </t>
 <t>
-   Also, if the response has a Last-Modified header field
+   Also, if the response has a <x:ref>Last-Modified</x:ref> header field
    (&header-last-modified;), caches are encouraged to use a heuristic
    expiration value that is no more than some fraction of the interval since
@@ -896 +896 @@
 </t>
 <t>
-   When sending such a conditional request, a cache adds an If-Modified-Since
-   header field whose value is that of the Last-Modified header field from the
-   selected (see <xref target="caching.negotiated.responses"/>) stored
-   response, if available.
-</t>
-<t>
-   Additionally, a cache can add an If-None-Match header field whose value is
-   that of the ETag header field(s) from all responses stored for the
-   requested URI, if present. However, if any of the stored responses contains
-   only partial content, the cache shouldn't include its entity-tag in the
-   If-None-Match header field unless the request is for a range that would be
-   fully satisfied by that stored response.
+   When sending such a conditional request, a cache adds an
+   <x:ref>If-Modified-Since</x:ref> header field whose value is that of the
+   <x:ref>Last-Modified</x:ref> header field from the selected
+   (see <xref target="caching.negotiated.responses"/>) stored response, if
+   available.
+</t>
+<t>
+   Additionally, a cache can add an <x:ref>If-None-Match</x:ref> header field
+   whose value is that of the <x:ref>ETag</x:ref> header field(s) from all
+   responses stored for the requested URI, if present. However, if any of the
+   stored responses contains only partial content, the cache shouldn't
+   include its entity-tag in the If-None-Match header field unless the request
+   is for a range that would be fully satisfied by that stored response.
 </t>
 
@@ -989 +990 @@
    If one or more stored GET responses can be selected (as per <xref
    target="caching.negotiated.responses"/>) for a HEAD request, and the
-   Content-Length, ETag or Last-Modified value of a HEAD response differs from
-   that in a selected GET response, the cache &MUST; consider that selected
-   response to be stale.
-</t>
-<t>
-   If the Content-Length, ETag and Last-Modified values of a HEAD response
-   (when present) are the same as that in a selected GET response (as per
-   <xref target="caching.negotiated.responses"/>), the cache &SHOULD; update the
-   remaining headers in the stored response using the following rules:
+   Content-Length, <x:ref>ETag</x:ref> or <x:ref>Last-Modified</x:ref> value of
+   a HEAD response differs from that in a selected GET response, the cache
+   &MUST; consider that selected response to be stale.
+</t>
+<t>
+   If the Content-Length, <x:ref>ETag</x:ref> and <x:ref>Last-Modified</x:ref>
+   values of a HEAD response (when present) are the same as that in a selected
+   GET response (as per <xref target="caching.negotiated.responses"/>), the
+   cache &SHOULD; update the remaining headers in the stored response using the
+   following rules:
    <list style="symbols">
       <t>delete any <x:ref>Warning</x:ref> header fields in the stored response
@@ -2331 +2333 @@
       <x:defines>304</x:defines>
       <x:defines>304 (Not Modified)</x:defines>
+      <x:defines>ETag</x:defines>
+      <x:defines>If-Modified-Since</x:defines>
+      <x:defines>If-None-Match</x:defines>
+      <x:defines>Last-Modified</x:defines>
     </x:source>
   </reference>