Ignore:
Timestamp:
May 6, 2013, 11:14:22 PM (7 years ago)
Author:
mnot@…
Message:

Editorial work on p6; partially deals with #469.

File:
1 edited

Legend:

Unmodified
Added
Removed

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

    r2232 r2234  
    144144</t>
    145145
    146 <section anchor="intro.purpose" title="Purpose">
    147146<iref item="cache" />
    148147<t>
    149148   An HTTP <x:dfn>cache</x:dfn> is a local store of response messages and the
    150    subsystem that controls its message storage, retrieval, and deletion. A
    151    cache stores cacheable responses in order to reduce the response time and
     149   subsystem that controls storage, retrieval, and deletion of messages in it.
     150   A cache stores cacheable responses in order to reduce the response time and
    152151   network bandwidth consumption on future, equivalent requests. Any client or
    153152   server &MAY; employ a cache, though a cache cannot be used by a server that
    … …  
    160159   <xref target="expiration.model" />, if the response can be reused without
    161160   "validation" (checking with the origin server to see if the cached response
    162    remains valid for this request).  A fresh cache response can therefore
    163    reduce both latency and network transfers each time it is reused.
     161   remains valid for this request).  A fresh response can therefore
     162   reduce both latency and network overhead each time it is reused.
    164163   When a cached response is not fresh, it might still be reusable if it can
    165164   be freshened by validation (<xref target="validation.model" />) or if the
    166    origin is unavailable.
    167 </t>
    168 </section>
     165   origin is unavailable (xref target="serving.stale.responses" />).
     166</t>
    169167
    170168<section anchor="intro.terminology" title="Terminology">
    … …  
    227225   <x:dfn>age</x:dfn>
    228226   <list>
    229       <t>The age of a response is the time since it was sent by, or
    230       successfully validated with, the origin server.</t>
     227      <t>The time since a response was sent by, or successfully validated
     228      with, the origin server.</t>
    231229   </list>
    232230</t>
    … …  
    244242   <list>
    245243      <t>The length of time between the generation of a response and its
    246       expiration time.</t>
     244      expiration time (either explicit or heuristic).</t>
    247245   </list>
    248246</t>
    … …  
    259257   <x:dfn>stale</x:dfn>
    260258   <list>
    261       <t>A response is stale if its age has passed its freshness lifetime
    262       (either explicit or heuristic).</t>
     259      <t>A response is stale if its age has passed its freshness lifetime.</t>
    263260   </list>
    264261</t>
    … …  
    267264   <x:dfn>validator</x:dfn>
    268265   <list>
    269       <t>A protocol element (e.g., an entity-tag or a <x:ref>Last-Modified</x:ref>
    270       time) that is used to find out whether a stored response is an equivalent
    271       copy of a representation. See &weak-and-strong;.</t>
     266      <t>A protocol element (e.g., an entity-tag or a
     267      <x:ref>Last-Modified</x:ref> time) that is used to find out whether a
     268      stored response is an equivalent copy of a representation. .</t>
    272269   </list>
    273270</t>
    … …  
    278275   <list>
    279276      <t>A validator that is defined by the origin server such that its
    280          current value will change if the representation data changes; i.e.,
    281          an entity-tag that is not marked as weak (&entity-tags;) or,
    282          if no entity-tag is provided, a <x:ref>Last-Modified</x:ref> value
    283          that is strong in the sense defined by &lastmod-comparison;.</t>
     277         current value will change if the representation data changes.
     278         See &weak-and-strong;</t>
    284279   </list>
    285280</t>
    … …  
    336331   in the cache.  Although caching is an entirely &OPTIONAL; feature of HTTP,
    337332   we assume that reusing the cached response is desirable and that such
    338    reuse is the default behavior when no requirement or locally-desired
     333   reuse is the default behavior when no requirement or local
    339334   configuration prevents it.  Therefore, HTTP cache requirements are focused
    340335   on preventing a cache from either storing a non-reusable response or
    341    reusing a stored response inappropriately.
     336   reusing a stored response inappropriately, rather than mandating that
     337   caches always store and reuse particular responses.
    342338</t>
    343339<t>
    … …  
    354350</t>
    355351<t>
    356    The default <x:dfn>cache key</x:dfn> consists of the request method and
     352   The primary <x:dfn>cache key</x:dfn> consists of the request method and
    357353   target URI.  However, since HTTP caches in common use today are typically
    358354   limited to caching responses to GET, many implementations simply decline
    359    other methods and use only the URI as the key.
     355   other methods and use only the URI as the primary cache key.
    360356</t>
    361357<t>
    … …  
    390386            <t>contains a max-age response cache directive (see <xref
    391387            target="cache-response-directive.max-age" />), or</t>
    392             <t>contains a s-maxage response cache directive and the cache is
     388            <t>contains a s-maxage response cache directive (see <xref
     389            target="cache-response-directive.s-maxage" />) and the cache is
    393390            shared, or</t>
    394391            <t>contains a Cache Control Extension (see <xref
    … …  
    409406<t>
    410407   In this context, a cache has "understood" a request method or a response
    411    status code if it recognizes it and implements any cache-specific
    412    behavior.
    413 </t>
    414 <t>
    415    Note that, in normal operation, many caches will not store a response that
     408   status code if it recognizes it and implements all specified
     409   caching-related behavior.
     410</t>
     411<t>
     412   Note that, in normal operation, some caches will not store a response that
    416413   has neither a cache validator nor an explicit expiration time, as such
    417414   responses are not usually useful to store. However, caches are not
    … …  
    474471   title="Constructing Responses from Caches">
    475472<t>
    476    For a presented request, a cache &MUST-NOT; send a stored response,
     473   When presented with a request, a cache &MUST-NOT; reuse a stored response,
    477474   unless:
    478475   <list style="symbols">
    … …  
    507504</t>
    508505<t>
    509    When a stored response is used to satisfy a request without validation,
    510    a cache &MUST; send a single <x:ref>Age</x:ref> header field
    511    (<xref target="header.age"/>) in the response with a value equal to the
    512    stored response's current_age; see <xref target="age.calculations" />.
     506   When a stored response is used to satisfy a request without validation, a
     507   cache &MUST; generate an <x:ref>Age</x:ref> header field (<xref
     508   target="header.age"/>), replacing any present in the response with a value
     509   equal to the stored response's current_age; see <xref
     510   target="age.calculations" />.
    513511</t>
    514512<t>
    … …  
    525523   When more than one suitable response is stored, a cache &MUST; use the
    526524   most recent response (as determined by the <x:ref>Date</x:ref> header
    527    field). It can also forward a request with "Cache-Control: max-age=0" or
     525   field). It can also forward the request with "Cache-Control: max-age=0" or
    528526   "Cache-Control: no-cache" to disambiguate which response to use.
    529527</t>
    530528<t>
    531529   A cache that does not have a clock available &MUST-NOT; use stored
    532    responses without revalidating them on every use.
    533 </t>
    534 
    535 
    536 <section anchor="expiration.model" title="Freshness Model">
     530   responses without revalidating them upon every use.
     531</t>
     532
     533
     534<section anchor="expiration.model" title="Freshness">
    537535<t>
    538536   When a response is "fresh" in the cache, it can be used to satisfy
    … …  
    571569</figure>
    572570<t>
    573    The freshness_lifetime is defined in <xref
    574    target="calculating.freshness.lifetime" />; the current_age is defined in
     571   freshness_lifetime is defined in <xref
     572   target="calculating.freshness.lifetime" />; current_age is defined in
    575573   <xref target="age.calculations" />.
    576574</t>
    … …  
    613611   When there is more than one value present for a given directive (e.g., two
    614612   <x:ref>Expires</x:ref> header fields, multiple Cache-Control: max-age
    615    directives), it is considered invalid. Caches are encouraged to consider
    616    responses that have invalid freshness information to be stale.
     613   directives), the directive's value is considered invalid. Caches are
     614   encouraged to consider responses that have invalid freshness information to
     615   be stale.
    617616</t>
    618617</section>
    … …  
    653652      from calculating heuristic freshness for URIs with query components
    654653      (i.e., those containing '?'). In practice, this has not been widely
    655       implemented. Therefore, servers are encouraged to send explicit
     654      implemented. Therefore, origin servers are encouraged to send explicit
    656655      directives (e.g., Cache-Control: no-cache) if they wish to preclude
    657656      caching.
    … …  
    811810</t>
    812811<t>
    813    If a cache receives a first-hand response (either an entire response, or a
    814    <x:ref>304 (Not Modified)</x:ref> response) that it would normally forward
    815    to the requesting client, and the received response is no longer fresh, the
    816    cache can forward it to the requesting client without adding a new
    817    <x:ref>Warning</x:ref> (but without removing any existing Warning header
    818    fields). A cache shouldn't attempt to validate a response simply because
    819    that response became stale in transit.
    820 </t>
    821 </section>
    822 </section>
    823 
    824 <section anchor="validation.model" title="Validation Model">
     812   note that if a cache receives a first-hand response (either an entire
     813   response, or a <x:ref>304 (Not Modified)</x:ref> response) that it would
     814   normally forward to the requesting client, and the received response is no
     815   longer fresh, the cache can forward it to the requesting client without
     816   adding a new <x:ref>Warning</x:ref> (but without removing any existing
     817   Warning header fields). A cache shouldn't attempt to validate a response
     818   simply because that response became stale in transit.
     819</t>
     820</section>
     821</section>
     822
     823<section anchor="validation.model" title="Validation">
    825824<t>
    826825   When a cache has one or more stored responses for a requested URI, but
    … …  
    841840<t>
    842841   Additionally, a cache can add an <x:ref>If-None-Match</x:ref> header field
    843    whose value is that of the <x:ref>ETag</x:ref> header field(s) from all
    844    responses stored for the requested URI, if present. However, if any of the
    845    stored responses contains only partial content, the cache shouldn't
    846    include its entity-tag in the If-None-Match header field unless the request
    847    is for a range that would be fully satisfied by that stored response.
     842   whose value is that of the <x:ref>ETag</x:ref> header field(s) from
     843   relevant responses stored for the primary cache key, if present. However,
     844   if any of the stored responses contains only partial content, the cache
     845   shouldn't include its entity-tag in the If-None-Match header field unless
     846   the request is for a range that would be fully satisfied by that stored
     847   response.
    848848</t>
    849849
    … …  
    889889    <t>
    890890     If the new response contains a strong validator, then that strong
    891      validator identifies the selected representation.  All of the stored
    892      responses with the same strong validator are selected.
    893      If none of the stored responses contain the same strong validator,
    894      then the new response &MUST-NOT; be used to update any stored responses.
     891     validator identifies the selected representation for update. All of the
     892     stored responses with the same strong validator are selected. If none of
     893     the stored responses contain the same strong validator, then the new
     894     response &MUST-NOT; be used to update any stored responses.
    895895    </t>
    896896    <t>
    897897     If the new response contains a weak validator and that validator
    898898     corresponds to one of the cache's stored responses, then the most
    899      recent of those matching stored responses is selected.
     899     recent of those matching stored responses is selected for update.
    900900    </t>
    901901    <t>
    … …  
    904904     source other than the Last-Modified response header field), and there is
    905905     only one stored response, and that stored response also lacks a
    906      validator, then that stored response is selected.
     906     validator, then that stored response is selected for update.
    907907    </t>
    908908   </list>
    … …  
    10791079<t>
    10801080   Note that this does not guarantee that all appropriate responses are
    1081    invalidated. For example, the request that caused the change at the origin
    1082    server might not have gone through the cache where a response is stored.
    1083 </t>
     1081   invalidated. For example, a state-changing request might invalidate
     1082   responses in the caches it travels through, but relevant responses still
     1083   might be stored in other caches that it has not.</t>
    10841084</section>
    10851085
    … …  
    11351135<x:note>
    11361136   <t>
    1137        &Note; HTTP/1.0 caches might not implement Cache-Control and
    1138        might only implement Pragma: no-cache (see <xref target="header.pragma"
    1139        />).
     1137       &Note; some HTTP/1.0 caches might not implement Cache-Control.
    11401138   </t>
    11411139</x:note>
    … …  
    12351233<t>
    12361234   The "max-stale" request directive indicates that the client is willing
    1237    to accept a response that has exceeded its expiration time. If max-stale
     1235   to accept a response that has exceeded its freshness lifetime. If max-stale
    12381236   is assigned a value, then the client is willing to accept a response
    1239    that has exceeded its expiration time by no more than the specified
     1237   that has exceeded its freshness lifetime by no more than the specified
    12401238   number of seconds. If no value is assigned to max-stale, then the client
    12411239   is willing to accept a stale response of any age.
    … …  
    13371335</t>
    13381336<t>
    1339    The field-names given are not limited to the set of standard header
     1337   The field-names given are not limited to the set of header
    13401338   fields defined by this specification. Field names are case-insensitive.
    13411339</t>
    … …  
    13831381</t>
    13841382<t>
    1385    The field-names given are not limited to the set of standard header
     1383   The field-names given are not limited to the set of header
    13861384   fields defined by this specification. Field names are case-insensitive.
    13871385</t>
    13881386<t>
    1389    &Note; Many HTTP/1.0 caches will not recognize or obey
    1390    this directive. Also, no-cache response directives with field-names are
    1391    often handled by implementations as if an unqualified no-cache directive
    1392    was received; i.e., the special handling for the qualified form is not
    1393    widely implemented.
     1387   &Note; Although it has been back-ported to many implementations, some
     1388   HTTP/1.0 caches will not recognize or obey this directive. Also, no-cache
     1389   response directives with field-names are often handled by implementations
     1390   as if an unqualified no-cache directive was received; i.e., the special
     1391   handling for the qualified form is not widely implemented.
    13941392</t>
    13951393<t>
    … …  
    15101508<t>
    15111509   The Cache-Control header field can be extended through the use of one or
    1512    more cache-extension tokens, each with an optional value. Informational
    1513    extensions (those that do not require a change in cache behavior) can be
    1514    added without changing the semantics of other directives. Behavioral
    1515    extensions are designed to work by acting as modifiers to the existing base
    1516    of cache directives. Both the new directive and the standard directive are
    1517    supplied, such that applications that do not understand the new directive
    1518    will default to the behavior specified by the standard directive, and those
    1519    that understand the new directive will recognize it as modifying the
    1520    requirements associated with the standard directive. In this way,
    1521    extensions to the cache-control directives can be made without requiring
    1522    changes to the base protocol.
     1510   more cache-extension tokens, each with an optional value.
     1511</t>
     1512<t>
     1513   Informational extensions (those that do not require a change in cache
     1514   behavior) can be added without changing the semantics of other directives.
     1515   Behavioral extensions are designed to work by acting as modifiers to the
     1516   existing base of cache directives.
     1517</t>
     1518<t>   
     1519   Both the new directive and the standard directive are supplied, such that
     1520   applications that do not understand the new directive will default to the
     1521   behavior specified by the standard directive, and those that understand the
     1522   new directive will recognize it as modifying the requirements associated
     1523   with the standard directive. In this way, extensions to the cache-control
     1524   directives can be made without requiring changes to the base protocol.
    15231525</t>
    15241526<t>
    … …  
    15611563      argument is present,</t>
    15621564      <t>When the directive requires an argument, what it means when it is
    1563       missing.</t>
     1565      missing,</t>
     1566      <t>Whether the directive is specific to requests, responses, or able
     1567        to be used in either.</t>
    15641568   </list>
    15651569</t>
Note: See TracChangeset for help on using the changeset viewer.