Ignore:
Timestamp:
May 7, 2013, 12:14:23 AM (7 years ago)
Author:
mnot@…
Message:

Distribute terminology throughout text; see #469

File:
1 edited

Legend:

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

    r2238 r2239  
    153153   is acting as a tunnel.
    154154</t>
     155<iref item="shared cache" />
     156<iref item="private cache" />
     157<t anchor="shared.and.non-shared.caches">
     158   A <x:dfn>shared cache</x:dfn> is a cache that stores responses to be reused
     159   by more than one user; shared caches are usually (but not always) deployed
     160   as a part of an intermediary. A <x:dfn>private cache</x:dfn>, in contrast,
     161   is dedicated to a single user.
     162</t>
    155163<t>
    156164   The goal of caching in HTTP/1.1 is to significantly improve performance
     
    166174</t>
    167175
    168 <section anchor="intro.terminology" title="Terminology">
    169 <t>
    170    This specification uses a number of terms to refer to the roles played by
    171    participants in, and objects of, HTTP caching.
    172 </t>
    173 <t>
    174    <iref item="cache" />
    175    <x:dfn>cache</x:dfn>
    176    <list>
    177       <t>A conformant implementation of an HTTP cache. Note that this implies
    178         an HTTP/1.1 cache; this specification does not define conformance
    179         for HTTP/1.0 caches.</t>
    180    </list>
    181 </t>
    182 <t anchor="shared.and.non-shared.caches">
    183    <iref item="shared cache" />
    184    <x:dfn>shared cache</x:dfn>
    185    <list>
    186       <t>A cache that stores responses to be reused by more than one user;
    187          usually (but not always) deployed as part of an intermediary.</t>
    188    </list>
    189 </t>
    190 <t>
    191    <iref item="private cache" />
    192    <x:dfn>private cache</x:dfn>
    193    <list>
    194       <t>A cache that is dedicated to a single user.</t>
    195    </list>
    196 </t>
    197 <t>
    198    <iref item="cacheable" />
    199    <x:dfn>cacheable</x:dfn>
    200    <list>
    201       <t>A response is cacheable if a cache is allowed to store a copy of the
    202       response message for use in answering subsequent requests. Even when a
    203       response is cacheable, there might be additional constraints on whether
    204       a cache can use the stored copy to satisfy a particular request.</t>
    205    </list>
    206 </t>
    207 <t>
    208    <iref item="explicit expiration time" />
    209    <x:dfn>explicit expiration time</x:dfn>
    210    <list>
    211       <t>The time at which the origin server intends that a stored response
    212       no longer be used by a cache without further validation.</t>
    213    </list>
    214 </t>
    215 <t>
    216    <iref item="heuristic expiration time" />
    217    <x:dfn>heuristic expiration time</x:dfn>
    218    <list>
    219       <t>An expiration time assigned by a cache when no explicit expiration
    220       time is available.</t>
    221    </list>
    222 </t>
    223 <t>
    224    <iref item="age" />
    225    <x:dfn>age</x:dfn>
    226    <list>
    227       <t>The time since a response was sent by, or successfully validated
    228       with, the origin server.</t>
    229    </list>
    230 </t>
    231 <t>
    232    <iref item="first-hand" />
    233    <x:dfn>first-hand</x:dfn>
    234    <list>
    235       <t>A response is first-hand if the freshness model is not in use; i.e.,
    236       its age is 0.</t>
    237    </list>
    238 </t>
    239 <t>
    240    <iref item="freshness lifetime" />
    241    <x:dfn>freshness lifetime</x:dfn>
    242    <list>
    243       <t>The length of time between the generation of a response and its
    244       expiration time (either explicit or heuristic).</t>
    245    </list>
    246 </t>
    247 <t>
    248    <iref item="fresh" />
    249    <x:dfn>fresh</x:dfn>
    250    <list>
    251       <t>A response is fresh if its age has not yet exceeded its freshness
    252       lifetime.</t>
    253    </list>
    254 </t>
    255 <t>
    256    <iref item="stale" />
    257    <x:dfn>stale</x:dfn>
    258    <list>
    259       <t>A response is stale if its age has passed its freshness lifetime.</t>
    260    </list>
    261 </t>
    262 <t>
    263    <iref item="validator" />
    264    <x:dfn>validator</x:dfn>
    265    <list>
    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>
    269    </list>
    270 </t>
    271 <t>
    272    <iref item="strong validator" />
    273    <iref item="validator" subitem="strong" />
    274    <x:dfn>strong validator</x:dfn>
    275    <list>
    276       <t>A validator that is defined by the origin server such that its
    277          current value will change if the representation data changes.
    278          See &weak-and-strong;</t>
    279    </list>
    280 </t>
    281 </section>
    282 
    283176<section title="Conformance and Error Handling" anchor="conformance">
    284177<t>
     
    349242   caching and defines something suitable for use as a cache key.
    350243</t>
     244<iref item="cache key" />
    351245<t>
    352246   The primary <x:dfn>cache key</x:dfn> consists of the request method and
     
    559453
    560454<section anchor="expiration.model" title="Freshness">
     455<iref item="fresh" />
     456<iref item="stale" />
     457<t>
     458   A <x:dfn>fresh</x:dfn> response is one whose age has not yet exceeded its
     459   freshness lifetime. Conversely, a <x:dfn>stale</x:dfn>
     460   response is one where it has.
     461</t>
     462<iref item="freshness lifetime" />
     463<iref item="explicit expiration time" />
     464<iref item="heuristic expiration time" />
     465<t>
     466   A response's <x:dfn>freshness lifetime</x:dfn> is the length of time
     467   between its generation by the origin server and its expiration time. An
     468   <x:dfn>explicit expiration time</x:dfn> is the time at which the origin
     469   server intends that a stored response can no longer be used by a cache
     470   without further validation, whereas a <x:dfn>heuristic expiration
     471   time</x:dfn> is assigned by a cache when no explicit expiriation time is
     472   available.
     473</t>
     474<iref item="age" />
     475<t>
     476   A response's <x:dfn>age</x:dfn> is the time that has passed since it was
     477   generated by, or successfully validated with, the origin server. 
     478</t>
    561479<t>
    562480   When a response is "fresh" in the cache, it can be used to satisfy
     
    569487   <x:ref>Expires</x:ref> header field (<xref target="header.expires" />) or
    570488   the max-age response cache directive (<xref
    571    target="cache-response-directive.max-age" />). Generally, origin servers will
    572    assign future explicit expiration times to responses in the belief that the
    573    representation is not likely to change in a semantically significant way
    574    before the expiration time is reached.
     489   target="cache-response-directive.max-age" />). Generally, origin servers
     490   will assign future explicit expiration times to responses in the belief
     491   that the representation is not likely to change in a semantically
     492   significant way before the expiration time is reached.
    575493</t>
    576494<t>
     
    798716   field (e.g., because there are no HTTP/1.0 hops in the <x:ref>Via</x:ref>
    799717   header field), in which case the corrected_age_value &MAY; be used as the
    800    corrected_initial_age.</t>
     718   corrected_initial_age.
     719</t>
    801720<t>
    802721   The current_age of a stored response can then be calculated by adding the
     
    835754   cache is disconnected.
    836755</t>
    837 <t>
    838    note that if a cache receives a first-hand response (either an entire
    839    response, or a <x:ref>304 (Not Modified)</x:ref> response) that it would
    840    normally forward to the requesting client, and the received response is no
    841    longer fresh, the cache can forward it to the requesting client without
    842    adding a new <x:ref>Warning</x:ref> (but without removing any existing
    843    Warning header fields). A cache shouldn't attempt to validate a response
    844    simply because that response became stale in transit.
     756<iref item="first-hand" />
     757<t>
     758   Note that if a cache receives a <x:dfn>first-hand</x:dfn> response (one
     759   where the freshness model is not in use; i.e., its age is 0, whether it is
     760   an entire response, or a <x:ref>304 (Not Modified)</x:ref> response) that
     761   it would normally forward to the requesting client, and the received
     762   response is no longer fresh, the cache can forward it to the requesting
     763   client without adding a new <x:ref>Warning</x:ref> (but without removing
     764   any existing Warning header fields). A cache shouldn't attempt to validate
     765   a response simply because that response became stale in transit.
    845766</t>
    846767</section>
     
    857778   "validating" or "revalidating" the stored response.
    858779</t>
    859 <t>
    860    When sending such a conditional request, a cache adds an
    861    <x:ref>If-Modified-Since</x:ref> header field whose value is that of the
    862    <x:ref>Last-Modified</x:ref> header field from the selected
    863    (see <xref target="caching.negotiated.responses"/>) stored response, if
    864    available.
    865 </t>
    866 <t>
    867    Additionally, a cache can add an <x:ref>If-None-Match</x:ref> header field
     780<iref item="validator" />
     781<t>
     782   When sending such a conditional request, a cache adds a
     783   <x:dfn>validator</x:dfn> (or more than one), that is used to find
     784   out whether a stored response is an equivalent copy of a current
     785   representation of the resource.
     786</t>
     787<t>
     788   One such validator is the <x:ref>If-Modified-Since</x:ref> header field,
     789   whose value is that of the <x:ref>Last-Modified</x:ref> header field from
     790   the selected (see <xref target="caching.negotiated.responses"/>) stored
     791   response, if available.
     792</t>
     793<t>
     794   Another is the <x:ref>If-None-Match</x:ref> header field,
    868795   whose value is that of the <x:ref>ETag</x:ref> header field(s) from
    869796   relevant responses stored for the primary cache key, if present. However,
     
    909836   with the new information provided in the <x:ref>304</x:ref> response.
    910837</t>
     838<iref item="strong validator" />
    911839<t>
    912840   The stored response to update is identified by using the first match (if
     
    914842   <list style="symbols">
    915843    <t>
    916      If the new response contains a strong validator, then that strong
    917      validator identifies the selected representation for update. All of the
    918      stored responses with the same strong validator are selected. If none of
    919      the stored responses contain the same strong validator, then the new
    920      response &MUST-NOT; be used to update any stored responses.
     844     If the new response contains a <x:dfn>strong validator</x:dfn> (see
     845     &weak-and-strong;), then that strong validator identifies the selected
     846     representation for update. All of the stored responses with the same
     847     strong validator are selected. If none of the stored responses contain
     848     the same strong validator, then the new response &MUST-NOT; be used to
     849     update any stored responses.
    921850    </t>
    922851    <t>
Note: See TracChangeset for help on using the changeset viewer.