Ignore:
Timestamp:
13/07/09 06:55:38 (11 years ago)
Author:
julian.reschke@…
Message:

Address Vary and non-existant headers (#37), and rearrange for clarity (merges changes from -07 into -latest)

File:
1 edited

Legend:

Unmodified
Added
Removed

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

    r604 r607  
    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" ?>
    … …  
    175176  <author fullname="Mark Nottingham" initials="M." role="editor" surname="Nottingham">
    176177    <organization />
    177     <address>           
    178       <email>mnot@mnot.net</email>     
    179       <uri>http://www.mnot.net/</uri>           
     178    <address>
     179      <email>mnot@mnot.net</email>
     180      <uri>http://www.mnot.net/</uri>
    180181    </address>
    181182  </author>
    … …  
    189190        <country>Germany</country>
    190191      </postal>
    191       <phone>+49 251 2807760</phone>   
    192       <facsimile>+49 251 2807761</facsimile>   
    193       <email>julian.reschke@greenbytes.de</email>       
    194       <uri>http://greenbytes.de/tech/webdav/</uri>     
     192      <phone>+49 251 2807760</phone>
     193      <facsimile>+49 251 2807761</facsimile>
     194      <email>julian.reschke@greenbytes.de</email>
     195      <uri>http://greenbytes.de/tech/webdav/</uri>
    195196    </address>
    196197  </author>
    … …  
    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
     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
    736750  request and replace the stored response. <cref>Should there be a requirement here?</cref>
    737751</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>
    … …  
    817834</t>
    818835<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>
     836  The stored response with matching selecting request-headers is known as the
     837  selected response.
     838</t>
     839<t>
     840  If no selected response is available, the cache &MAY; forward the presented
     841  request to the origin server in a conditional request; see <xref target="validation.model"/>.
    837842</t>
    838843</section>
    … …  
    840845<section anchor="combining.headers" title="Combining Responses">
    841846<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
     847  When a cache receives a 304 (Not Modified) response or a 206 (Partial Content) response
     848  (in this section, the "new" response"), it needs to created an updated response by combining
     849  the stored response with the new one, so that the updated response can be used to satisfy the request.
     850</t>
     851<t>
     852  If the new response contains an ETag, it identifies the stored 
     853  response to use. <cref>may need language about Content-Location 
     854  here</cref><cref>cover case where INM with multiple etags was sent</cref>
     855</t>
     856<t>
     857  If the status code is 206 (partial content), both the stored and new 
     858  responses &MUST; have ETags, and those ETags &MUST; match using the strong 
     859  comparison function (see &weak-and-strong;). Otherwise, the 
     860  responses &MUST-NOT; be combined.
     861</t>
     862<t>
     863  The stored response headers are used as those of the updated response, except that
    855864  <list style="symbols">
    856865    <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>
     866      &MUST; be deleted from the stored response and the updated response.</t>
    858867    <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
     868      response and the updated response.</t>
     869    <t>any headers provided in the new response &MUST; replace the corresponding
    861870      headers from the stored response.</t>
    862871  </list>
    863872</t>
    864873<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.
     874  If a header field-name in the new response matches more than one 
     875  header in the stored response, all such stored headers &MUST; be replaced.
     876</t>
     877<t>
     878  The updated response can [[<cref>requirement?</cref>]] be used to replace the 
     879  stored response in cache. In the case of a 206 response, the combined 
     880  entity-body &MAY; be stored.
    870881</t>
    871882<t>
    … …  
    23242335  </list>
    23252336</t>
     2337<t>
     2338  Affected issues:
     2339  <list style="symbols">
     2340    <t>
     2341      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/37"/>:
     2342      Vary and non-existant headers
     2343    </t>
     2344  </list>
     2345</t>
    23262346</section>
    23272347
Note: See TracChangeset for help on using the changeset viewer.