Changeset 484


Ignore:
Timestamp:
Mar 3, 2009, 9:05:11 PM (11 years ago)
Author:
mnot@…
Message:

rework caching negotiated responses.

File:
1 edited

Legend:

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

    r483 r484  
    695695
    696696      <section anchor="caching.negotiated.responses" title="Caching Negotiated Responses">
    697         <t>Use of server-driven content negotiation (&server-driven-negotiation;), as indicated
    698           by the presence of a Vary header field (<xref target="header.vary" />) in a response, alters
     697        <t>Use of server-driven content negotiation (&server-driven-negotiation;) alters
    699698          the conditions and procedure by which a cache can use the response for subsequent
    700699          requests.</t>
    701         <t>When the cache receives a subsequent request which may be satisfied by a stored responses
    702           that include a Vary header field, it &MUST-NOT; use it to satisfy the request unless
     700        <t>When the cache receives a request which may be satisfied by a stored response
     701          that includes a Vary header field, it &MUST-NOT; use the stored response to satisfy the request unless
    703702          all of the selecting request-headers present in the new request match the corresponding
    704703          stored request-headers from the original request.</t>
     
    708707          <cref>[ref]</cref> at places where this is allowed by the corresponding ABNF, and/or
    709708          combining multiple message-header fields with the same field name following the rules
    710           about message headers in &message-headers;.</t>
    711         <t>A Vary header field-value of "*" always fails to match, and subsequent requests on that
     709          about message headers in &message-headers;. <cref>DISCUSS: header-specific canonicalisation</cref></t>
     710        <t>A Vary header field-value of "*" always fails to match, and subsequent requests to that
    712711          resource can only be properly interpreted by the origin server.</t>
    713         <t>If the selecting request-headers for the stored response do not match the selecting
    714           request header fields of the new request, then the cache &MUST-NOT; use the stored
    715           response to satisfy the request unless it first relays the new request to the origin
    716           server in a conditional request and the server responds with 304 (Not Modified), including
    717           an entity tag or Content-Location that indicates the entity to be used.</t>
    718         <t>If one or more applicable stored response has an entity tag, the forwarded request
    719           &SHOULD; be conditional and include all of these entity tags in an If-None-Match
    720           header field. This conveys to the server the set of entities currently stored by the
    721           cache, so that if any one of these entities matches the requested entity, the server can
    722           use the ETag header field in its 304 (Not Modified) response to tell the cache which
    723           stored response is appropriate. If the entity-tag of the new response matches that of an
    724           existing stored resopnse, the new response &SHOULD; be used to update its header
    725           fields, and the result &MUST; be returned to the client.</t>
    726         <t>If any of the existing stored responses contains only partial content for the associated
    727           entity, its entity-tag &SHOULD-NOT; be included in the If-None-Match header field
    728           unless the request is for a range that would be fully satisfied by that stored response.</t>
     712        <t>If they fail to match, the cache &MAY; forward the presented request to the origin
     713          server in a conditional request, which &SHOULD; include all ETags stored with
     714          potentially suitable responses in an If-None-Match request header. If the server responds with 304 (Not Modified) and
     715          includes an entity tag or Content-Location that indicates the entity to be used, that
     716          cached response &MUST; be used to satisfy the presented request, and &SHOULD;
     717          be used to update the corresponding stored response; see <xref target="combining.headers"/>.</t>
     718        <t>If any of the stored responses contains only partial content, its entity-tag &SHOULD-NOT;
     719          be included in the If-None-Match header field unless the request is for a range that would
     720          be fully satisfied by that stored response.</t>
    729721        <t>If a cache receives a successful response whose Content-Location field matches that of an
    730722          existing stored response for the same Request-URI, whose entity-tag differs from that of
    731723          the existing stored response, and whose Date is more recent than that of the existing
    732724          response, the existing response &SHOULD-NOT; be returned in response to future
    733           requests and &SHOULD; be deleted from the cache.</t>
    734         <t>
    735           <cref>TODO: this still needs work.</cref>
    736         </t>
     725          requests and &SHOULD; be deleted from the cache.<cref>DISCUSS: Not sure if this is necessary.</cref></t>
    737726      </section>
    738727
Note: See TracChangeset for help on using the changeset viewer.