Ignore:
Timestamp:
07/09/13 19:26:15 (8 years ago)
Author:
fielding@…
Message:

(editorial) move the discussion of secondary keys next to primary keys before moving p4 cache requirements; fix typo

File:
1 edited

Legend:

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

    r2369 r2371  
    452452</t>
    453453
     454<section anchor="caching.negotiated.responses"
     455   title="Calculating Secondary Keys with Vary">
     456<t>
     457   When a cache receives a request that can be satisfied by a stored response
     458   that has a <x:ref>Vary</x:ref> header field (&header-vary;),
     459   it &MUST-NOT; use that response unless all of the selecting header fields
     460   nominated by the Vary header field match in both the original request
     461   (i.e., that associated with the stored response), and the presented
     462   request.
     463</t>
     464<t>
     465   The selecting header fields from two requests are defined to match if and
     466   only if those in the first request can be transformed to those in the
     467   second request by applying any of the following:
     468   <list style="symbols">
     469      <t>
     470         adding or removing whitespace, where allowed in the header field's
     471         syntax
     472      </t>
     473      <t>
     474         combining multiple header fields with the same field name
     475         (see &header-fields;)
     476      </t>
     477      <t>
     478         normalizing both header field values in a way that is known to have
     479         identical semantics, according to the header field's specification
     480         (e.g., re-ordering field values when order is not significant;
     481         case-normalization, where values are defined to be case-insensitive)
     482      </t>
     483  </list>
     484</t>
     485<t>
     486   If (after any normalization that might take place) a header field is absent
     487   from a request, it can only match another request if it is also absent
     488   there.
     489</t>
     490<t>
     491   A <x:ref>Vary</x:ref> header field-value of "*" always fails to match.
     492</t>
     493<t>
     494   The stored response with matching selecting header fields is known as the
     495   selected response.
     496</t>
     497<t>
     498   If multiple selected responses are available (potentially including
     499   responses without a Vary header field), the cache will need to choose one to use.
     500   When a selecting header field has a known mechanism for doing so (e.g., qvalues on
     501   <x:ref>Accept</x:ref> and similar request header fields), that mechanism &MAY; be
     502   used to select preferred responses; of the remainder, the most recent
     503   response (as determined by the <x:ref>Date</x:ref> header field) is used, as
     504   per <xref target="constructing.responses.from.caches"/>.
     505</t>
     506<t>
     507   If no selected response is available, the cache cannot satisfy the
     508   presented request. Typically, it is forwarded to the origin server
     509   in a (possibly conditional; see <xref target="validation.model"/>) request.
     510</t>
     511</section>
    454512
    455513<section anchor="expiration.model" title="Freshness">
     
    470528   server intends that a stored response can no longer be used by a cache
    471529   without further validation, whereas a <x:dfn>heuristic expiration
    472    time</x:dfn> is assigned by a cache when no explicit expiriation time is
     530   time</x:dfn> is assigned by a cache when no explicit expiration time is
    473531   available.
    474532</t>
     
    878936</section>
    879937
    880 </section>
    881 
    882 <section anchor="caching.negotiated.responses"
    883    title="Calculating Secondary Keys with Vary">
    884 <t>
    885    When a cache receives a request that can be satisfied by a stored response
    886    that has a <x:ref>Vary</x:ref> header field (&header-vary;),
    887    it &MUST-NOT; use that response unless all of the selecting header fields
    888    nominated by the Vary header field match in both the original request
    889    (i.e., that associated with the stored response), and the presented
    890    request.
    891 </t>
    892 <t>
    893    The selecting header fields from two requests are defined to match if and
    894    only if those in the first request can be transformed to those in the
    895    second request by applying any of the following:
    896    <list style="symbols">
    897       <t>
    898          adding or removing whitespace, where allowed in the header field's
    899          syntax
    900       </t>
    901       <t>
    902          combining multiple header fields with the same field name
    903          (see &header-fields;)
    904       </t>
    905       <t>
    906          normalizing both header field values in a way that is known to have
    907          identical semantics, according to the header field's specification
    908          (e.g., re-ordering field values when order is not significant;
    909          case-normalization, where values are defined to be case-insensitive)
    910       </t>
    911   </list>
    912 </t>
    913 <t>
    914    If (after any normalization that might take place) a header field is absent
    915    from a request, it can only match another request if it is also absent
    916    there.
    917 </t>
    918 <t>
    919    A <x:ref>Vary</x:ref> header field-value of "*" always fails to match.
    920 </t>
    921 <t>
    922    The stored response with matching selecting header fields is known as the
    923    selected response.
    924 </t>
    925 <t>
    926    If multiple selected responses are available (potentially including
    927    responses without a Vary header field), the cache will need to choose one to use.
    928    When a selecting header field has a known mechanism for doing so (e.g., qvalues on
    929    <x:ref>Accept</x:ref> and similar request header fields), that mechanism &MAY; be
    930    used to select preferred responses; of the remainder, the most recent
    931    response (as determined by the <x:ref>Date</x:ref> header field) is used, as
    932    per <xref target="constructing.responses.from.caches"/>.
    933 </t>
    934 <t>
    935    If no selected response is available, the cache cannot satisfy the
    936    presented request. Typically, it is forwarded to the origin server
    937    in a (possibly conditional; see <xref target="validation.model"/>) request.
    938 </t>
    939938</section>
    940939
Note: See TracChangeset for help on using the changeset viewer.