Changeset 2179


Ignore:
Timestamp:
Feb 10, 2013, 10:10:25 PM (7 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

Location:
draft-ietf-httpbis/latest
Files:
2 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p2-semantics.xml

    r2177 r2179  
    43054305</t>
    43064306<t>
    4307    A definition for a new status code ought to explain the request
     4307   The definition of a new status code ought to explain the request
    43084308   conditions that would cause a response containing that status code (e.g.,
    43094309   combinations of request header fields and/or method(s)) along with any
     
    43134313</t>
    43144314<t>
    4315    A response that can transfer a payload ought to specify expected cache
    4316    behavior (e.g., cacheability and freshness criteria, as described in
    4317    &caching;) and whether the payload has any implied association with an
    4318    identified resource (<xref target="identifying.payload"/>).
     4315   The definition of a new status code ought to specify whether or not it is
     4316   cacheable. Note that all status codes can be cached if the response they
     4317   occur in has explicit freshness information; however, status codes that are
     4318   defined as being cacheable are allowed to be cached without explicit
     4319   freshness information. Likewise, the definition of a status code can place
     4320   constraints upon cache behaviour. See &caching; for more information.
     4321</t>
     4322<t>   
     4323   Finally, the definition of a new status code ought to indicate whether the
     4324   payload has any implied association with an identified resource (<xref
     4325   target="identifying.payload"/>).
    43194326</t>
    43204327</section>
  • draft-ietf-httpbis/latest/p6-cache.xml

    r2177 r2179  
    395395            target="cache.control.extensions" />) that allows it to be cached,
    396396            or</t>
    397             <t>has a status code that can be served with heuristic freshness
    398             (see <xref target="heuristic.freshness" />).</t>
     397            <t>has a status code that is defined as cacheable
     398            (see <xref target="heuristic.freshness" />), or</t>
     399            <t>contains a public response cache directive.</t>
    399400         </list>
    400401      </t>
     
    556557</t>
    557558<t>
    558    Since origin servers do not always provide explicit expiration times, a
    559    cache &MAY; assign a heuristic expiration time when an explicit time is not
    560    specified, employing algorithms that use other header field values (such as
    561    the <x:ref>Last-Modified</x:ref> time) to estimate a plausible expiration
    562    time. This specification does not provide specific algorithms, but does
    563    impose worst-case constraints on their results.
     559   Since origin servers do not always provide explicit expiration times,
     560   caches are also allowed to use a heuristic to determine an expiration time
     561   under certain circumstances (see <xref target="heuristic.freshness"/>).
    564562</t>
    565563<figure>
     
    621619<section anchor="heuristic.freshness" title="Calculating Heuristic Freshness">
    622620<t>
    623    A cache &MUST-NOT; use heuristics to determine freshness unless no explicit
    624    expiration time is present in a stored response and either the status code
    625    is defined as cacheable by default (including the following in
    626    &status-codes;: <x:ref>200 (OK)</x:ref>, <x:ref>203 (Non-Authoritative
    627    Information)</x:ref>, <x:ref>206 (Partial Content)</x:ref>, <x:ref>300
    628    (Multiple Choices)</x:ref>, <x:ref>301 (Moved Permanently)</x:ref> and
    629    <x:ref>410 (Gone)</x:ref>) or the response has been explicitly marked as
    630    cacheable (e.g., by using the public directive without a max-age).
     621   Since origin servers do not always provide explicit expiration times, a
     622   cache &MAY; assign a heuristic expiration time when an explicit time is not
     623   specified, employing algorithms that use other header field values (such as
     624   the <x:ref>Last-Modified</x:ref> time) to estimate a plausible expiration
     625   time. This specification does not provide specific algorithms, but does
     626   impose worst-case constraints on their results.
     627</t>
     628<t>
     629   A cache &MUST-NOT; use heuristics to determine freshness when an explicit
     630   expiration time is present in the stored response. Because of the
     631   requirements in <xref target="response.cacheability"/>, this means that,
     632   effectively, heuristics can only be used on responses without explicit
     633   freshness whose status codes are defined as cacheable, and responses
     634   without explicit freshness that have been marked as explicitly cacheable
     635   (e.g., with a "public" response cache directive).
     636</t>
     637<t>
     638   If the response has a <x:ref>Last-Modified</x:ref> header field
     639   (&header-last-modified;), caches are encouraged to use a heuristic
     640   expiration value that is no more than some fraction of the interval since
     641   that time. A typical setting of this fraction might be 10%.
    631642</t>
    632643<t>
     
    635646   response if its current_age is more than 24 hours and such a warning is not
    636647   already present.
    637 </t>
    638 <t>
    639    Also, if the response has a <x:ref>Last-Modified</x:ref> header field
    640    (&header-last-modified;), caches are encouraged to use a heuristic
    641    expiration value that is no more than some fraction of the interval since
    642    that time. A typical setting of this fraction might be 10%.
    643648</t>
    644649<x:note>
     
    12971302<t>
    12981303   The "public" response directive indicates that any cache &MAY; store the
    1299    response and reuse it for later requests, even if the response would
    1300    normally be non-cacheable or cacheable only within a non-shared cache.
    1301    (See <xref target="caching.authenticated.responses"/> for additional
    1302    details related to the use of public in response to a request containing
    1303    <x:ref>Authorization</x:ref>.)
     1304   response, even if the response would normally be non-cacheable or cacheable
     1305   only within a non-shared cache. (See <xref
     1306   target="caching.authenticated.responses"/> for additional details related
     1307   to the use of public in response to a request containing
     1308   <x:ref>Authorization</x:ref>, and <xref target="response.cacheability"/>
     1309   for details of how public affects responses that would normally not be
     1310   stored, due to their status codes not being defined as cacheable.)
    13041311</t>
    13051312</section>
Note: See TracChangeset for help on using the changeset viewer.