Ignore:
Timestamp:
Jul 12, 2009, 11:58:01 PM (10 years ago)
Author:
julian.reschke@…
Message:

Regenerate ready-to-submit drafts; update diffs.

File:
1 edited

Legend:

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

    r605 r608  
    145145  <author fullname="Mark Nottingham" initials="M." role="editor" surname="Nottingham">
    146146    <organization/>
    147     <address>           
    148       <email>mnot@mnot.net</email>     
    149       <uri>http://www.mnot.net/</uri>           
     147    <address>
     148      <email>mnot@mnot.net</email>
     149      <uri>http://www.mnot.net/</uri>
    150150    </address>
    151151  </author>
     
    159159        <country>Germany</country>
    160160      </postal>
    161       <phone>+49 251 2807760</phone>   
    162       <facsimile>+49 251 2807761</facsimile>   
    163       <email>julian.reschke@greenbytes.de</email>       
    164       <uri>http://greenbytes.de/tech/webdav/</uri>     
     161      <phone>+49 251 2807760</phone>
     162      <facsimile>+49 251 2807761</facsimile>
     163      <email>julian.reschke@greenbytes.de</email>
     164      <uri>http://greenbytes.de/tech/webdav/</uri>
    165165    </address>
    166166  </author>
     
    680680<section anchor="validation.model" title="Validation Model">
    681681<t>
    682   Checking with the origin server to see if a stale or otherwise unusable cached response
    683   can be reused is called "validating" or "revalidating." Doing so potentially avoids
    684   the overhead of retransmitting the response body when the stored response is valid.
    685 </t>
    686 <t>
    687   HTTP's conditional request mechanism <xref target="Part4"/> is used for this purpose. When a stored
    688   response includes one or more validators, such as the field values of an ETag or
    689   Last-Modified header field, then a validating request SHOULD be made conditional
    690   to those field values.
     682  When a cache has one or more stored responses for a requested URI, but cannot 
     683  serve any of them (e.g., because they are not fresh, or one cannot be selected;
     684  see <xref target="caching.negotiated.responses"/>),
     685  it can use the conditional request mechanism <xref target="Part4"/> in the forwarded
     686  request to give the origin server an opportunity to both select a valid stored
     687  response to be used, and to update it. This process is known as "validating"
     688  or "revalidating" the stored response.
     689</t>
     690<t>
     691  When sending such a conditional request, the cache SHOULD add an If-Modified-Since
     692  header whose value is that of the Last-Modified header from the selected
     693  (see <xref target="caching.negotiated.responses"/>) stored response, if available.
     694</t>
     695<t>
     696  Additionally, the cache SHOULD add an If-None-Match header whose value 
     697  is that of the ETag header(s) from all responses stored for the requested URI,
     698  if present. However, if any of the stored responses contains only partial
     699  content, its entity-tag SHOULD NOT be included in the If-None-Match header
     700  field unless the request is for a range that would be fully satisfied by
     701  that stored response.
    691702</t>
    692703<t>
     
    695706</t>
    696707<t>
    697   If instead the cache receives a full response (i.e., one with a response body), it is used to satisfy the
     708  A full response (i.e., one with a response body) indicates that none 
     709  of the stored responses nominated in the conditional request is
     710  suitable. Instead, the full response is used both to satisfy the
    698711  request and replace the stored response. <cref>Should there be a requirement here?</cref>
    699712</t>
     
    701714  If a cache receives a 5xx response while attempting to validate a response, it MAY
    702715  either forward this response to the requesting client, or act as if the server failed to
    703   respond. In the latter case, it MAY return a previously stored response (which SHOULD include the
    704   111 warn-code; see <xref target="header.warning"/>) unless the
    705   stored response includes the "must-revalidate" cache directive (see <xref target="serving.stale.responses"/>).
     716  respond. In the latter case, it MAY return a previously stored response (see <xref target="serving.stale.responses"/>).
     717</t>
     718<t>
     719  If a cache receives a successful response whose Content-Location field 
     720  matches that of an existing stored response for the same Request-URI, 
     721  whose entity-tag differs from that of the existing stored response, 
     722  and whose Date is more recent than that of the existing response, the 
     723  existing response SHOULD NOT be returned in response to future 
     724  requests and SHOULD be deleted from the cache. <cref>DISCUSS: Not 
     725  sure if this is necessary.</cref>
    706726</t>
    707727</section>
     
    751771<section anchor="caching.negotiated.responses" title="Caching Negotiated Responses">
    752772<t>
    753   Use of server-driven content negotiation (Section 4.1 of <xref target="Part3"/>) alters
    754   the conditions under which a cache can use the response for subsequent
    755   requests.
    756 </t>
    757 <t>
    758773  When a cache receives a request that can be satisfied by a stored response
    759   that includes a Vary header field (<xref target="header.vary"/>), it MUST NOT use that response unless
    760   all of the selecting request-headers in the presented request match the corresponding
    761   stored request-headers from the original request.
     774  that has a Vary header field (<xref target="header.vary"/>), it MUST NOT use that
     775  response unless all of the selecting request-headers nominated by the Vary header match
     776  in both the original request (i.e., that associated with the stored response),
     777  and the presented request.
    762778</t>
    763779<t>
     
    767783  <cref>[ref]</cref> at places where this is allowed by the corresponding ABNF, and/or
    768784  combining multiple message-header fields with the same field name following the rules
    769   about message headers in Section 4.2 of <xref target="Part1"/>. <cref anchor="DISCUSS-header-specific-canonicalization">
    770   Should the matching requirement be relaxed so that it would be ok to use a cached response
    771   if the selecting request headers match after header-specific canonicalization?
    772   (see &lt;http://trac.tools.ietf.org/wg/httpbis/trac/ticket/147&gt;)
    773   </cref>
     785  about message headers in Section 4.2 of <xref target="Part1"/>.
     786</t>
     787<t>
     788  If a header field is absent from a request, it can only match another request
     789  if it is also absent there.
    774790</t>
    775791<t>
     
    778794</t>
    779795<t>
    780   If no stored response matches, the cache MAY forward the presented request to the origin
    781   server in a conditional request, and SHOULD include all ETags stored with
    782   potentially suitable responses in an If-None-Match request header. If the server responds with 304 (Not Modified) and
    783   includes an entity tag or Content-Location that indicates the entity to be used, that
    784   cached response MUST be used to satisfy the presented request, and SHOULD
    785   be used to update the corresponding stored response; see <xref target="combining.headers"/>.
    786 </t>
    787 <t>
    788   If any of the stored responses contains only partial content, its entity-tag SHOULD NOT
    789   be included in the If-None-Match header field unless the request is for a range that would
    790   be fully satisfied by that stored response.
    791 </t>
    792 <t>
    793   If a cache receives a successful response whose Content-Location field matches that of an
    794   existing stored response for the same Request-URI, whose entity-tag differs from that of
    795   the existing stored response, and whose Date is more recent than that of the existing
    796   response, the existing response SHOULD NOT be returned in response to future
    797   requests and SHOULD be deleted from the cache.<cref>DISCUSS: Not sure if this is necessary.</cref>
     796  The stored response with matching selecting request-headers is known as the
     797  selected response.
     798</t>
     799<t>
     800  If no selected response is available, the cache MAY forward the presented
     801  request to the origin server in a conditional request; see <xref target="validation.model"/>.
    798802</t>
    799803</section>
     
    801805<section anchor="combining.headers" title="Combining Responses">
    802806<t>
    803   When a cache receives a 304 (Not Modified) response or a 206 (Partial Content) response,
    804   it needs to update the stored response with the new one, so that the updated response can
    805   be sent to the client.
    806 </t>
    807 <t>
    808   If the status code is 304 (Not Modified), the cache SHOULD use the stored entity-body as
    809   the updated entity-body. If the status code is 206 (Partial Content) and the ETag or
    810   Last-Modified headers match exactly, the cache MAY combine the stored entity-body in
    811   the stored response with the updated entity-body received in the response and use the
    812   result as the updated entity-body (see Section 4 of <xref target="Part5"/>).
    813 </t>
    814 <t>
    815   The stored response headers are used for the updated response, except that
     807  When a cache receives a 304 (Not Modified) response or a 206 (Partial Content) response
     808  (in this section, the "new" response"), it needs to created an updated response by combining
     809  the stored response with the new one, so that the updated response can be used to satisfy the request.
     810</t>
     811<t>
     812  If the new response contains an ETag, it identifies the stored 
     813  response to use. <cref>may need language about Content-Location 
     814  here</cref><cref>cover case where INM with multiple etags was sent</cref>
     815</t>
     816<t>
     817  If the status code is 206 (partial content), both the stored and new 
     818  responses MUST have ETags, and those ETags MUST match using the strong 
     819  comparison function (see Section 4 of <xref target="Part4"/>). Otherwise, the 
     820  responses MUST NOT be combined.
     821</t>
     822<t>
     823  The stored response headers are used as those of the updated response, except that
    816824  <list style="symbols">
    817825    <t>any stored Warning headers with warn-code 1xx (see <xref target="header.warning"/>)
    818       MUST be deleted from the stored response and the forwarded response.</t>
     826      MUST be deleted from the stored response and the updated response.</t>
    819827    <t>any stored Warning headers with warn-code 2xx MUST be retained in the stored
    820       response and the forwarded response.</t>
    821     <t>any headers provided in the 304 or 206 response MUST replace the corresponding
     828      response and the updated response.</t>
     829    <t>any headers provided in the new response MUST replace the corresponding
    822830      headers from the stored response.</t>
    823831  </list>
    824832</t>
    825833<t>
    826   A cache MUST also replace any stored headers with corresponding headers received in the
    827   incoming response, except for Warning headers as described immediately above. If a header
    828   field-name in the incoming response matches more than one header in the stored response,
    829   all such old headers MUST be replaced. It MAY store the combined
    830   entity-body.
     834  If a header field-name in the new response matches more than one 
     835  header in the stored response, all such stored headers MUST be replaced.
     836</t>
     837<t>
     838  The updated response can [[<cref>requirement?</cref>]] be used to replace the 
     839  stored response in cache. In the case of a 206 response, the combined 
     840  entity-body MAY be stored.
    831841</t>
    832842<t>
     
    22862296  </list>
    22872297</t>
     2298<t>
     2299  Affected issues:
     2300  <list style="symbols">
     2301    <t>
     2302      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/37"/>:
     2303      Vary and non-existant headers
     2304    </t>
     2305  </list>
     2306</t>
    22882307</section>
    22892308
Note: See TracChangeset for help on using the changeset viewer.