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

Timestamp:

11/02/13 06:10:25 (8 years ago)

Author:

mnot@…

Message:

Tidy up discussion of heuristic freshness, with follow-on effects in the
definition of 'public', the storage algorithm, and considerations for new
status codes. Addresses #223

File:

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

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

@@ -395 +395 @@
             target="cache.control.extensions" />) that allows it to be cached,
             or</t>
-            <t>has a status code that can be served with heuristic freshness
-            (see <xref target="heuristic.freshness" />).</t>
+            <t>has a status code that is defined as cacheable
+            (see <xref target="heuristic.freshness" />), or</t>
+            <t>contains a public response cache directive.</t>
          </list>
       </t>
@@ -556 +557 @@
 </t>
 <t>
-   Since origin servers do not always provide explicit expiration times, 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 <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.
+   Since origin servers do not always provide explicit expiration times,
+   caches are also allowed to use a heuristic to determine an expiration time
+   under certain circumstances (see <xref target="heuristic.freshness"/>).
 </t>
 <figure>
@@ -621 +619 @@
 <section anchor="heuristic.freshness" title="Calculating Heuristic Freshness">
 <t>
-   A cache &MUST-NOT; use heuristics to determine freshness unless no explicit
-   expiration time is present in a stored response and either the status code
-   is defined as cacheable by default (including the following in
-   &status-codes;: <x:ref>200 (OK)</x:ref>, <x:ref>203 (Non-Authoritative
-   Information)</x:ref>, <x:ref>206 (Partial Content)</x:ref>, <x:ref>300
-   (Multiple Choices)</x:ref>, <x:ref>301 (Moved Permanently)</x:ref> and
-   <x:ref>410 (Gone)</x:ref>) or the response has been explicitly marked as
-   cacheable (e.g., by using the public directive without a max-age).
+   Since origin servers do not always provide explicit expiration times, 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 <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>
+<t>
+   A cache &MUST-NOT; use heuristics to determine freshness when an explicit
+   expiration time is present in the stored response. Because of the
+   requirements in <xref target="response.cacheability"/>, this means that,
+   effectively, heuristics can only be used on responses without explicit
+   freshness whose status codes are defined as cacheable, and responses
+   without explicit freshness that have been marked as explicitly cacheable
+   (e.g., with a "public" response cache directive).
+</t>
+<t>
+   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
+   that time. A typical setting of this fraction might be 10%.
 </t>
 <t>
@@ -635 +646 @@
    response if its current_age is more than 24 hours and such a warning is not
    already present.
-</t>
-<t>
-   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
-   that time. A typical setting of this fraction might be 10%.
 </t>
 <x:note>
@@ -1297 +1302 @@
 <t>
    The "public" response directive indicates that any cache &MAY; store the
-   response and reuse it for later requests, even if the response would
-   normally be non-cacheable or cacheable only within a non-shared cache.
-   (See <xref target="caching.authenticated.responses"/> for additional
-   details related to the use of public in response to a request containing
-   <x:ref>Authorization</x:ref>.)
+   response, even if the response would normally be non-cacheable or cacheable
+   only within a non-shared cache. (See <xref
+   target="caching.authenticated.responses"/> for additional details related
+   to the use of public in response to a request containing
+   <x:ref>Authorization</x:ref>, and <xref target="response.cacheability"/>
+   for details of how public affects responses that would normally not be
+   stored, due to their status codes not being defined as cacheable.)
 </t>
 </section>