Changeset 606 for draft-ietf-httpbis/07


Ignore:
Timestamp:
13/07/09 02:56:55 (11 years ago)
Author:
mnot@…
Message:

Address Vary and non-existant headers (#37), and rearrange for clarity

File:
1 edited

Legend:

Unmodified
Added
Removed

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

    r604 r606  
    3333  <!ENTITY safe-methods                "<xref target='Part2' x:rel='#safe.methods' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3434  <!ENTITY server-driven-negotiation   "<xref target='Part3' x:rel='#server-driven.negotiation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     35  <!ENTITY weak-and-strong                         "<xref target='Part4' x:rel='#weak.and.strong.validators' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3536]>
    3637<?rfc toc="yes" ?>
    … …  
    718719<section anchor="validation.model" title="Validation Model">
    719720<t>
    720   Checking with the origin server to see if a stale or otherwise unusable cached response
    721   can be reused is called "validating" or "revalidating." Doing so potentially avoids
    722   the overhead of retransmitting the response body when the stored response is valid.
    723 </t>
    724 <t>
    725   HTTP's conditional request mechanism &conditional; is used for this purpose. When a stored
    726   response includes one or more validators, such as the field values of an ETag or
    727   Last-Modified header field, then a validating request &SHOULD; be made conditional
    728   to those field values.
     721        When a cache has one or more stored responses for a requested URI, but cannot 
     722        serve any of them (e.g., because they are not fresh, or one cannot be selected;
     723        see <xref target="caching.negotiated.responses"/>),
     724        it can use the conditional request mechanism &conditional; in the forwarded
     725        request to give the origin server an opportunity to both select a valid stored
     726        response to be used, and to update it. This process is known as "validating"
     727        or "revalidating" the stored response.
     728</t>
     729<t>     
     730        When sending such a conditional request, the cache &SHOULD; add an If-Modified-Since
     731        header whose value is that of the Last-Modified header from the selected
     732        (see <xref target="caching.negotiated.responses"/>) stored response, if available.
     733</t>
     734<t>     
     735        Additionally, the cache &SHOULD; add an If-None-Match header whose value 
     736        is that of the ETag header(s) from all responses stored for the requested URI,
     737        if present. However, if any of the stored responses contains only partial
     738        content, its entity-tag &SHOULD-NOT; be included in the If-None-Match header
     739        field unless the request is for a range that would be fully satisfied by
     740        that stored response.
    729741</t>
    730742<t>
    … …  
    733745</t>
    734746<t>
    735   If instead the cache receives a full response (i.e., one with a response body), it is used to satisfy the
    736   request and replace the stored response. <cref>Should there be a requirement here?</cref>
     747        A full response (i.e., one with a response body) indicates that none 
     748        of the stored responses nominated in the conditional request is
     749        suitable. Instead, the full response is used both to satisfy the
     750        request and replace the stored response. <cref>Should there be a requirement here?</cref>
    737751</t>
    738752<t>
    739753  If a cache receives a 5xx response while attempting to validate a response, it &MAY;
    740754  either forward this response to the requesting client, or act as if the server failed to
    741   respond. In the latter case, it &MAY; return a previously stored response (which &SHOULD; include the
    742   111 warn-code; see <xref target="header.warning"/>) unless the
    743   stored response includes the "must-revalidate" cache directive (see <xref
     755  respond. In the latter case, it &MAY; return a previously stored response (see <xref
    744756  target="serving.stale.responses" />).
     757</t>
     758<t>
     759        If a cache receives a successful response whose Content-Location field 
     760        matches that of an existing stored response for the same Request-URI, 
     761        whose entity-tag differs from that of the existing stored response, 
     762        and whose Date is more recent than that of the existing response, the 
     763        existing response &SHOULD-NOT; be returned in response to future 
     764        requests and &SHOULD; be deleted from the cache. <cref>DISCUSS: Not 
     765        sure if this is necessary.</cref>
    745766</t>
    746767</section>
    … …  
    790811<section anchor="caching.negotiated.responses" title="Caching Negotiated Responses">
    791812<t>
    792   Use of server-driven content negotiation (&server-driven-negotiation;) alters
    793   the conditions under which a cache can use the response for subsequent
    794   requests.
    795 </t>
    796 <t>
    797813  When a cache receives a request that can be satisfied by a stored response
    798   that includes a Vary header field (<xref target="header.vary"/>), it &MUST-NOT; use that response unless
    799   all of the selecting request-headers in the presented request match the corresponding
    800   stored request-headers from the original request.
     814  that has a Vary header field (<xref target="header.vary"/>), it &MUST-NOT; use that
     815  response unless all of the selecting request-headers nominated by the Vary header match
     816  in both the original request (i.e., that associated with the stored response),
     817  and the presented request.
    801818</t>
    802819<t>
    … …  
    806823  <cref>[ref]</cref> at places where this is allowed by the corresponding ABNF, and/or
    807824  combining multiple message-header fields with the same field name following the rules
    808   about message headers in &message-headers;. <cref anchor="DISCUSS-header-specific-canonicalization">
    809   Should the matching requirement be relaxed so that it would be ok to use a cached response
    810   if the selecting request headers match after header-specific canonicalization?
    811   (see <eref target="http://trac.tools.ietf.org/wg/httpbis/trac/ticket/147">Issue 147</eref>)
    812   </cref>
     825  about message headers in &message-headers;.
     826</t>
     827<t>     
     828        If a header field is absent from a request, it can only match another request
     829        if it is also absent there.
    813830</t>
    814831<t>
    … …  
    816833  resource can only be properly interpreted by the origin server.
    817834</t>
    818 <t>
    819   If no stored response matches, the cache &MAY; forward the presented request to the origin
    820   server in a conditional request, and &SHOULD; include all ETags stored with
    821   potentially suitable responses in an If-None-Match request header. If the server responds with 304 (Not Modified) and
    822   includes an entity tag or Content-Location that indicates the entity to be used, that
    823   cached response &MUST; be used to satisfy the presented request, and &SHOULD;
    824   be used to update the corresponding stored response; see <xref target="combining.headers"/>.
    825 </t>
    826 <t>
    827   If any of the stored responses contains only partial content, its entity-tag &SHOULD-NOT;
    828   be included in the If-None-Match header field unless the request is for a range that would
    829   be fully satisfied by that stored response.
    830 </t>
    831 <t>
    832   If a cache receives a successful response whose Content-Location field matches that of an
    833   existing stored response for the same Request-URI, whose entity-tag differs from that of
    834   the existing stored response, and whose Date is more recent than that of the existing
    835   response, the existing response &SHOULD-NOT; be returned in response to future
    836   requests and &SHOULD; be deleted from the cache.<cref>DISCUSS: Not sure if this is necessary.</cref>
     835<t>The stored response with matching selecting request-headers is known as the
     836selected response.
     837</t>
     838<t>
     839  If no selected response is available, the cache &MAY; forward the presented
     840  request to the origin server in a conditional request; see <xref target="validation.model"/>.
    837841</t>
    838842</section>
    … …  
    840844<section anchor="combining.headers" title="Combining Responses">
    841845<t>
    842   When a cache receives a 304 (Not Modified) response or a 206 (Partial Content) response,
    843   it needs to update the stored response with the new one, so that the updated response can
    844   be sent to the client.
    845 </t>
    846 <t>
    847   If the status code is 304 (Not Modified), the cache &SHOULD; use the stored entity-body as
    848   the updated entity-body. If the status code is 206 (Partial Content) and the ETag or
    849   Last-Modified headers match exactly, the cache &MAY; combine the stored entity-body in
    850   the stored response with the updated entity-body received in the response and use the
    851   result as the updated entity-body (see &combining-byte-ranges;).
    852 </t>
    853 <t>
    854   The stored response headers are used for the updated response, except that
     846  When a cache receives a 304 (Not Modified) response or a 206 (Partial Content) response
     847  (in this section, the "new" response"), it needs to created an updated response by combining
     848  the stored response with the new one, so that the updated response can be used to satisfy the request.
     849</t>
     850<t>
     851        If the new response contains an ETag, it identifies the stored 
     852        response to use. <cref>may need language about Content-Location 
     853        here</cref><cref>cover case where INM with multiple etags was sent</cref>
     854</t>
     855<t>
     856        If the status code is 206 (partial content), both the stored and new 
     857        responses &MUST; have ETags, and those ETags &MUST; match using the strong 
     858        comparison function (see &weak-and-strong;). Otherwise, the 
     859        responses &MUST-NOT; be combined.
     860</t>
     861<t>
     862  The stored response headers are used as those of the updated response, except that
    855863  <list style="symbols">
    856864    <t>any stored Warning headers with warn-code 1xx (see <xref target="header.warning" />)
    857       &MUST; be deleted from the stored response and the forwarded response.</t>
     865      &MUST; be deleted from the stored response and the updated response.</t>
    858866    <t>any stored Warning headers with warn-code 2xx &MUST; be retained in the stored
    859       response and the forwarded response.</t>
    860     <t>any headers provided in the 304 or 206 response &MUST; replace the corresponding
     867      response and the updated response.</t>
     868    <t>any headers provided in the new response &MUST; replace the corresponding
    861869      headers from the stored response.</t>
    862870  </list>
    863871</t>
    864872<t>
    865   A cache &MUST; also replace any stored headers with corresponding headers received in the
    866   incoming response, except for Warning headers as described immediately above. If a header
    867   field-name in the incoming response matches more than one header in the stored response,
    868   all such old headers &MUST; be replaced. It &MAY; store the combined
    869   entity-body.
     873        If a header field-name in the new response matches more than one 
     874        header in the stored response, all such stored headers &MUST; be replaced.
     875</t>
     876<t>     
     877        The updated response can [[<cref>requirement?</cref>]] be used to replace the 
     878        stored response in cache. In the case of a 206 response, the combined 
     879        entity-body &MAY; be stored.
    870880</t>
    871881<t>
    … …  
    23242334  </list>
    23252335</t>
     2336<t>
     2337  Affected issues:
     2338  <list style="symbols">
     2339    <t>
     2340      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/37"/>:
     2341      Vary and non-existant headers
     2342    </t>
     2343  </list>
     2344</t>
    23262345</section>
    23272346
Note: See TracChangeset for help on using the changeset viewer.