Ignore:
Timestamp:
Jul 12, 2009, 11:55:38 PM (10 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/07/p6-cache.xml

    r606 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'/>">
     35  <!ENTITY weak-and-strong             "<xref target='Part4' x:rel='#weak.and.strong.validators' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3636]>
    3737<?rfc toc="yes" ?>
     
    176176  <author fullname="Mark Nottingham" initials="M." role="editor" surname="Nottingham">
    177177    <organization />
    178     <address>           
    179       <email>mnot@mnot.net</email>     
    180       <uri>http://www.mnot.net/</uri>           
     178    <address>
     179      <email>mnot@mnot.net</email>
     180      <uri>http://www.mnot.net/</uri>
    181181    </address>
    182182  </author>
     
    190190        <country>Germany</country>
    191191      </postal>
    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>     
     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>
    196196    </address>
    197197  </author>
     
    719719<section anchor="validation.model" title="Validation Model">
    720720<t>
    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.
     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.
    741741</t>
    742742<t>
     
    745745</t>
    746746<t>
    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>
     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>
    751751</t>
    752752<t>
     
    757757</t>
    758758<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>
     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>
    766766</t>
    767767</section>
     
    825825  about message headers in &message-headers;.
    826826</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.
     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.
    830830</t>
    831831<t>
     
    833833  resource can only be properly interpreted by the origin server.
    834834</t>
    835 <t>The stored response with matching selecting request-headers is known as the
    836 selected response.
     835<t>
     836  The stored response with matching selecting request-headers is known as the
     837  selected response.
    837838</t>
    838839<t>
     
    849850</t>
    850851<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.
     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.
    860861</t>
    861862<t>
     
    871872</t>
    872873<t>
    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.
     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.
    880881</t>
    881882<t>
Note: See TracChangeset for help on using the changeset viewer.