* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Changeset 607


Ignore:
Timestamp:
2009-07-12 23:55:38 (5 years ago)
Author:
julian.reschke@gmx.de
Message:

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

Location:
draft-ietf-httpbis
Files:
3 edited

Legend:

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

    r604 r607  
    870870      </p> 
    871871      <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a>&nbsp;<a id="validation.model" href="#validation.model">Validation Model</a></h2> 
    872       <p id="rfc.section.2.4.p.1">Checking with the origin server to see if a stale or otherwise unusable cached response can be reused is called "validating" 
    873          or "revalidating." Doing so potentially avoids the overhead of retransmitting the response body when the stored response is 
    874          valid. 
    875       </p> 
    876       <p id="rfc.section.2.4.p.2">HTTP's conditional request mechanism <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a> is used for this purpose. When a stored response includes one or more validators, such as the field values of an ETag or Last-Modified 
    877          header field, then a validating request <em class="bcp14">SHOULD</em> be made conditional to those field values. 
    878       </p> 
    879       <p id="rfc.section.2.4.p.3">A 304 (Not Modified) response status code indicates that the stored response can be updated and reused; see <a href="#combining.headers" title="Combining Responses">Section&nbsp;2.7</a>. 
    880       </p> 
    881       <p id="rfc.section.2.4.p.4">If instead the cache receives a full response (i.e., one with a response body), it is used to satisfy the request and replace 
    882          the stored response. <span class="comment" id="rfc.comment.5">[<a href="#rfc.comment.5" class="smpl">rfc.comment.5</a>: Should there be a requirement here?]</span>  
    883       </p> 
    884       <p id="rfc.section.2.4.p.5">If a cache receives a 5xx response while attempting to validate a response, it <em class="bcp14">MAY</em> either forward this response to the requesting client, or act as if the server failed to respond. In the latter case, it <em class="bcp14">MAY</em> return a previously stored response (which <em class="bcp14">SHOULD</em> include the 111 warn-code; see <a href="#header.warning" id="rfc.xref.header.warning.2" title="Warning">Section&nbsp;3.6</a>) unless the stored response includes the "must-revalidate" cache directive (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section&nbsp;2.3.3</a>). 
     872      <p id="rfc.section.2.4.p.1">When a cache has one or more stored responses for a requested URI, but cannot serve any of them (e.g., because they are not 
     873         fresh, or one cannot be selected; see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;2.6</a>), it can use the conditional request mechanism <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a> in the forwarded request to give the origin server an opportunity to both select a valid stored response to be used, and to 
     874         update it. This process is known as "validating" or "revalidating" the stored response. 
     875      </p> 
     876      <p id="rfc.section.2.4.p.2">When sending such a conditional request, the cache <em class="bcp14">SHOULD</em> add an If-Modified-Since header whose value is that of the Last-Modified header from the selected (see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;2.6</a>) stored response, if available. 
     877      </p> 
     878      <p id="rfc.section.2.4.p.3">Additionally, the cache <em class="bcp14">SHOULD</em> add an If-None-Match header whose value is that of the ETag header(s) from all responses stored for the requested URI, if 
     879         present. However, if any of the stored responses contains only partial content, its entity-tag <em class="bcp14">SHOULD NOT</em> be included in the If-None-Match header field unless the request is for a range that would be fully satisfied by that stored 
     880         response. 
     881      </p> 
     882      <p id="rfc.section.2.4.p.4">A 304 (Not Modified) response status code indicates that the stored response can be updated and reused; see <a href="#combining.headers" title="Combining Responses">Section&nbsp;2.7</a>. 
     883      </p> 
     884      <p id="rfc.section.2.4.p.5">A full response (i.e., one with a response body) indicates that none of the stored responses nominated in the conditional 
     885         request is suitable. Instead, the full response is used both to satisfy the request and replace the stored response. <span class="comment" id="rfc.comment.5">[<a href="#rfc.comment.5" class="smpl">rfc.comment.5</a>: Should there be a requirement here?]</span>  
     886      </p> 
     887      <p id="rfc.section.2.4.p.6">If a cache receives a 5xx response while attempting to validate a response, it <em class="bcp14">MAY</em> either forward this response to the requesting client, or act as if the server failed to respond. In the latter case, it <em class="bcp14">MAY</em> return a previously stored response (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section&nbsp;2.3.3</a>). 
     888      </p> 
     889      <p id="rfc.section.2.4.p.7">If a cache receives a successful response whose Content-Location field matches that of an existing stored response for the 
     890         same Request-URI, whose entity-tag differs from that of the existing stored response, and whose Date is more recent than that 
     891         of the existing response, the existing response <em class="bcp14">SHOULD NOT</em> be returned in response to future requests and <em class="bcp14">SHOULD</em> be deleted from the cache. <span class="comment" id="rfc.comment.6">[<a href="#rfc.comment.6" class="smpl">rfc.comment.6</a>: DISCUSS: Not sure if this is necessary.]</span>  
    885892      </p> 
    886893      <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a>&nbsp;<a id="invalidation.after.updates.or.deletions" href="#invalidation.after.updates.or.deletions">Request Methods that Invalidate</a></h2> 
     
    897904         attacks. 
    898905      </p> 
    899       <p id="rfc.section.2.5.p.4"> <span class="comment" id="rfc.comment.6">[<a href="#rfc.comment.6" class="smpl">rfc.comment.6</a>: TODO: "host part" needs to be specified better.]</span>  
     906      <p id="rfc.section.2.5.p.4"> <span class="comment" id="rfc.comment.7">[<a href="#rfc.comment.7" class="smpl">rfc.comment.7</a>: TODO: "host part" needs to be specified better.]</span>  
    900907      </p> 
    901908      <p id="rfc.section.2.5.p.5">A cache that passes through requests for methods it does not understand <em class="bcp14">SHOULD</em> invalidate the Request-URI. 
     
    907914         change at the origin server might not have gone through the cache where a response is stored. 
    908915      </p> 
    909       <p id="rfc.section.2.5.p.8"> <span class="comment" id="rfc.comment.7">[<a href="#rfc.comment.7" class="smpl">rfc.comment.7</a>: TODO: specify that only successful (2xx, 3xx?) responses invalidate.]</span>  
     916      <p id="rfc.section.2.5.p.8"> <span class="comment" id="rfc.comment.8">[<a href="#rfc.comment.8" class="smpl">rfc.comment.8</a>: TODO: specify that only successful (2xx, 3xx?) responses invalidate.]</span>  
    910917      </p> 
    911918      <h2 id="rfc.section.2.6"><a href="#rfc.section.2.6">2.6</a>&nbsp;<a id="caching.negotiated.responses" href="#caching.negotiated.responses">Caching Negotiated Responses</a></h2> 
    912       <p id="rfc.section.2.6.p.1">Use of server-driven content negotiation (<a href="p3-payload.html#server-driven.negotiation" title="Server-driven Negotiation">Section 4.1</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) alters the conditions under which a cache can use the response for subsequent requests. 
    913       </p> 
    914       <p id="rfc.section.2.6.p.2">When a cache receives a request that can be satisfied by a stored response that includes a Vary header field (<a href="#header.vary" id="rfc.xref.header.vary.1" title="Vary">Section&nbsp;3.5</a>), it <em class="bcp14">MUST NOT</em> use that response unless all of the selecting request-headers in the presented request match the corresponding stored request-headers 
    915          from the original request. 
    916       </p> 
    917       <p id="rfc.section.2.6.p.3">The selecting request-headers from two requests are defined to match if and only if the selecting request-headers in the first 
    918          request can be transformed to the selecting request-headers in the second request by adding or removing linear white space <span class="comment" id="rfc.comment.8">[<a href="#rfc.comment.8" class="smpl">rfc.comment.8</a>: [ref]]</span> at places where this is allowed by the corresponding ABNF, and/or combining multiple message-header fields with the same field 
    919          name following the rules about message headers in <a href="p1-messaging.html#message.headers" title="Message Headers">Section 4.2</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. <span class="comment" id="DISCUSS-header-specific-canonicalization">[<a href="#DISCUSS-header-specific-canonicalization" class="smpl">DISCUSS-header-specific-canonicalization</a>: Should the matching requirement be relaxed so that it would be ok to use a cached response if the selecting request headers 
    920             match after header-specific canonicalization? (see <a href="http://trac.tools.ietf.org/wg/httpbis/trac/ticket/147">Issue 147</a>)]</span>  
    921       </p> 
     919      <p id="rfc.section.2.6.p.1">When a cache receives a request that can be satisfied by a stored response that has a Vary header field (<a href="#header.vary" id="rfc.xref.header.vary.1" title="Vary">Section&nbsp;3.5</a>), it <em class="bcp14">MUST NOT</em> use that response unless all of the selecting request-headers nominated by the Vary header match in both the original request 
     920         (i.e., that associated with the stored response), and the presented request. 
     921      </p> 
     922      <p id="rfc.section.2.6.p.2">The selecting request-headers from two requests are defined to match if and only if the selecting request-headers in the first 
     923         request can be transformed to the selecting request-headers in the second request by adding or removing linear white space <span class="comment" id="rfc.comment.9">[<a href="#rfc.comment.9" class="smpl">rfc.comment.9</a>: [ref]]</span> at places where this is allowed by the corresponding ABNF, and/or combining multiple message-header fields with the same field 
     924         name following the rules about message headers in <a href="p1-messaging.html#message.headers" title="Message Headers">Section 4.2</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 
     925      </p> 
     926      <p id="rfc.section.2.6.p.3">If a header field is absent from a request, it can only match another request if it is also absent there.</p> 
    922927      <p id="rfc.section.2.6.p.4">A Vary header field-value of "*" always fails to match, and subsequent requests to that resource can only be properly interpreted 
    923928         by the origin server. 
    924929      </p> 
    925       <p id="rfc.section.2.6.p.5">If no stored response matches, the cache <em class="bcp14">MAY</em> forward the presented request to the origin server in a conditional request, and <em class="bcp14">SHOULD</em> include all ETags stored with potentially suitable responses in an If-None-Match request header. If the server responds with 
    926          304 (Not Modified) and includes an entity tag or Content-Location that indicates the entity to be used, that cached response <em class="bcp14">MUST</em> be used to satisfy the presented request, and <em class="bcp14">SHOULD</em> be used to update the corresponding stored response; see <a href="#combining.headers" title="Combining Responses">Section&nbsp;2.7</a>. 
    927       </p> 
    928       <p id="rfc.section.2.6.p.6">If any of the stored responses contains only partial content, its entity-tag <em class="bcp14">SHOULD NOT</em> be included in the If-None-Match header field unless the request is for a range that would be fully satisfied by that stored 
    929          response. 
    930       </p> 
    931       <p id="rfc.section.2.6.p.7">If a cache receives a successful response whose Content-Location field matches that of an existing stored response for the 
    932          same Request-URI, whose entity-tag differs from that of the existing stored response, and whose Date is more recent than that 
    933          of the existing response, the existing response <em class="bcp14">SHOULD NOT</em> be returned in response to future requests and <em class="bcp14">SHOULD</em> be deleted from the cache.<span class="comment" id="rfc.comment.9">[<a href="#rfc.comment.9" class="smpl">rfc.comment.9</a>: DISCUSS: Not sure if this is necessary.]</span>  
     930      <p id="rfc.section.2.6.p.5">The stored response with matching selecting request-headers is known as the selected response.</p> 
     931      <p id="rfc.section.2.6.p.6">If no selected response is available, the cache <em class="bcp14">MAY</em> forward the presented request to the origin server in a conditional request; see <a href="#validation.model" title="Validation Model">Section&nbsp;2.4</a>. 
    934932      </p> 
    935933      <h2 id="rfc.section.2.7"><a href="#rfc.section.2.7">2.7</a>&nbsp;<a id="combining.headers" href="#combining.headers">Combining Responses</a></h2> 
    936       <p id="rfc.section.2.7.p.1">When a cache receives a 304 (Not Modified) response or a 206 (Partial Content) response, it needs to update the stored response 
    937          with the new one, so that the updated response can be sent to the client. 
    938       </p> 
    939       <p id="rfc.section.2.7.p.2">If the status code is 304 (Not Modified), the cache <em class="bcp14">SHOULD</em> use the stored entity-body as the updated entity-body. If the status code is 206 (Partial Content) and the ETag or Last-Modified 
    940          headers match exactly, the cache <em class="bcp14">MAY</em> combine the stored entity-body in the stored response with the updated entity-body received in the response and use the result 
    941          as the updated entity-body (see <a href="p5-range.html#combining.byte.ranges" title="Combining Ranges">Section 4</a> of <a href="#Part5" id="rfc.xref.Part5.3"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>). 
    942       </p> 
    943       <p id="rfc.section.2.7.p.3">The stored response headers are used for the updated response, except that </p> 
     934      <p id="rfc.section.2.7.p.1">When a cache receives a 304 (Not Modified) response or a 206 (Partial Content) response (in this section, the "new" response"), 
     935         it needs to created an updated response by combining the stored response with the new one, so that the updated response can 
     936         be used to satisfy the request. 
     937      </p> 
     938      <p id="rfc.section.2.7.p.2">If the new response contains an ETag, it identifies the stored response to use. <span class="comment" id="rfc.comment.10">[<a href="#rfc.comment.10" class="smpl">rfc.comment.10</a>: may need language about Content-Location here]</span><span class="comment" id="rfc.comment.11">[<a href="#rfc.comment.11" class="smpl">rfc.comment.11</a>: cover case where INM with multiple etags was sent]</span>  
     939      </p> 
     940      <p id="rfc.section.2.7.p.3">If the status code is 206 (partial content), both the stored and new responses <em class="bcp14">MUST</em> have ETags, and those ETags <em class="bcp14">MUST</em> match using the strong comparison function (see <a href="p4-conditional.html#weak.and.strong.validators" title="Weak and Strong Validators">Section 4</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>). Otherwise, the responses <em class="bcp14">MUST NOT</em> be combined. 
     941      </p> 
     942      <p id="rfc.section.2.7.p.4">The stored response headers are used as those of the updated response, except that </p> 
    944943      <ul> 
    945          <li>any stored Warning headers with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.3" title="Warning">Section&nbsp;3.6</a>) <em class="bcp14">MUST</em> be deleted from the stored response and the forwarded response. 
    946          </li> 
    947          <li>any stored Warning headers with warn-code 2xx <em class="bcp14">MUST</em> be retained in the stored response and the forwarded response. 
    948          </li> 
    949          <li>any headers provided in the 304 or 206 response <em class="bcp14">MUST</em> replace the corresponding headers from the stored response. 
     944         <li>any stored Warning headers with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.2" title="Warning">Section&nbsp;3.6</a>) <em class="bcp14">MUST</em> be deleted from the stored response and the updated response. 
     945         </li> 
     946         <li>any stored Warning headers with warn-code 2xx <em class="bcp14">MUST</em> be retained in the stored response and the updated response. 
     947         </li> 
     948         <li>any headers provided in the new response <em class="bcp14">MUST</em> replace the corresponding headers from the stored response. 
    950949         </li> 
    951950      </ul> 
    952       <p id="rfc.section.2.7.p.4">A cache <em class="bcp14">MUST</em> also replace any stored headers with corresponding headers received in the incoming response, except for Warning headers as 
    953          described immediately above. If a header field-name in the incoming response matches more than one header in the stored response, 
    954          all such old headers <em class="bcp14">MUST</em> be replaced. It <em class="bcp14">MAY</em> store the combined entity-body. 
    955       </p> 
    956       <p id="rfc.section.2.7.p.5"> <span class="comment" id="rfc.comment.10">[<a href="#rfc.comment.10" class="smpl">rfc.comment.10</a>: ISSUE: discuss how to handle HEAD updates]</span>  
     951      <p id="rfc.section.2.7.p.5">If a header field-name in the new response matches more than one header in the stored response, all such stored headers <em class="bcp14">MUST</em> be replaced. 
     952      </p> 
     953      <p id="rfc.section.2.7.p.6">The updated response can [[<span class="comment" id="rfc.comment.12">[<a href="#rfc.comment.12" class="smpl">rfc.comment.12</a>: requirement?]</span>]] be used to replace the stored response in cache. In the case of a 206 response, the combined entity-body <em class="bcp14">MAY</em> be stored. 
     954      </p> 
     955      <p id="rfc.section.2.7.p.7"> <span class="comment" id="rfc.comment.13">[<a href="#rfc.comment.13" class="smpl">rfc.comment.13</a>: ISSUE: discuss how to handle HEAD updates]</span>  
    957956      </p> 
    958957      <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="header.fields" href="#header.fields">Header Field Definitions</a></h1> 
     
    10401039            time. If max-stale is assigned a value, then the client is willing to accept a response that has exceeded its expiration time 
    10411040            by no more than the specified number of seconds. If no value is assigned to max-stale, then the client is willing to accept 
    1042             a stale response of any age. <span class="comment" id="rfc.comment.11">[<a href="#rfc.comment.11" class="smpl">rfc.comment.11</a>: of any staleness? --mnot]</span></dd> 
     1041            a stale response of any age. <span class="comment" id="rfc.comment.14">[<a href="#rfc.comment.14" class="smpl">rfc.comment.14</a>: of any staleness? --mnot]</span></dd> 
    10431042      </dl> 
    10441043      <p id="rfc.section.3.2.1.p.6"> <span id="rfc.iref.c.8"></span>  <span id="rfc.iref.m.3"></span> min-fresh  
     
    14281427                  <td>http</td> 
    14291428                  <td>standard</td> 
    1430                   <td> <a href="#header.warning" id="rfc.xref.header.warning.4" title="Warning">Section&nbsp;3.6</a>  
     1429                  <td> <a href="#header.warning" id="rfc.xref.header.warning.3" title="Warning">Section&nbsp;3.6</a>  
    14311430                  </td> 
    14321431               </tr> 
     
    15441543      <p id="rfc.section.A.1.p.2">Transfer-coding and message lengths all interact in ways that required fixing exactly when chunked encoding is used (to allow 
    15451544         for transfer encoding that may not be self delimiting); it was important to straighten out exactly how message lengths are 
    1546          computed. (see also <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a> and <a href="#Part5" id="rfc.xref.Part5.4"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) <span class="comment" id="rfc.comment.12">[<a href="#rfc.comment.12" class="smpl">rfc.comment.12</a>: This used to refer to the text about non-modifiable headers, and will have to be updated later on. --jre]</span>  
    1547       </p> 
    1548       <p id="rfc.section.A.1.p.3">Proxies should be able to add Content-Length when appropriate. <span class="comment" id="rfc.comment.13">[<a href="#rfc.comment.13" class="smpl">rfc.comment.13</a>: This used to refer to the text about non-modifiable headers, and will have to be updated later on. --jre]</span>  
     1545         computed. (see also <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a> and <a href="#Part5" id="rfc.xref.Part5.3"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) <span class="comment" id="rfc.comment.15">[<a href="#rfc.comment.15" class="smpl">rfc.comment.15</a>: This used to refer to the text about non-modifiable headers, and will have to be updated later on. --jre]</span>  
     1546      </p> 
     1547      <p id="rfc.section.A.1.p.3">Proxies should be able to add Content-Length when appropriate. <span class="comment" id="rfc.comment.16">[<a href="#rfc.comment.16" class="smpl">rfc.comment.16</a>: This used to refer to the text about non-modifiable headers, and will have to be updated later on. --jre]</span>  
    15491548      </p> 
    15501549      <p id="rfc.section.A.1.p.4">Range request responses would become very verbose if all meta-data were always returned; by allowing the server to only send 
     
    15531552      <p id="rfc.section.A.1.p.5">The Cache-Control: max-age directive was not properly defined for responses. (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;3.2.2</a>) 
    15541553      </p> 
    1555       <p id="rfc.section.A.1.p.6">Warnings could be cached incorrectly, or not updated appropriately. (Section <a href="#expiration.model" title="Freshness Model">2.3</a>, <a href="#combining.headers" title="Combining Responses">2.7</a>, <a href="#header.cache-control" id="rfc.xref.header.cache-control.7" title="Cache-Control">3.2</a>, and <a href="#header.warning" id="rfc.xref.header.warning.5" title="Warning">3.6</a>) Warning also needed to be a general header, as PUT or other methods may have need for it in requests. 
     1554      <p id="rfc.section.A.1.p.6">Warnings could be cached incorrectly, or not updated appropriately. (Section <a href="#expiration.model" title="Freshness Model">2.3</a>, <a href="#combining.headers" title="Combining Responses">2.7</a>, <a href="#header.cache-control" id="rfc.xref.header.cache-control.7" title="Cache-Control">3.2</a>, and <a href="#header.warning" id="rfc.xref.header.warning.4" title="Warning">3.6</a>) Warning also needed to be a general header, as PUT or other methods may have need for it in requests. 
    15561555      </p> 
    15571556      <h2 id="rfc.section.A.2"><a href="#rfc.section.A.2">A.2</a>&nbsp;<a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2> 
     
    17171716      <ul> 
    17181717         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/161">http://tools.ietf.org/wg/httpbis/trac/ticket/161</a>&gt;: "base for numeric protocol elements" 
     1718         </li> 
     1719      </ul> 
     1720      <p id="rfc.section.C.8.p.2">Affected issues: </p> 
     1721      <ul> 
     1722         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/37">http://tools.ietf.org/wg/httpbis/trac/ticket/37</a>&gt;: Vary and non-existant headers 
    17191723         </li> 
    17201724      </ul> 
     
    18001804                        <li class="indline1">Pragma&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.pragma.1">2.2</a>, <a class="iref" href="#rfc.xref.header.pragma.2">3.2</a>, <a class="iref" href="#rfc.iref.h.5"><b>3.4</b></a>, <a class="iref" href="#rfc.xref.header.pragma.3">5.1</a></li> 
    18011805                        <li class="indline1">Vary&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.vary.1">2.6</a>, <a class="iref" href="#rfc.iref.h.6"><b>3.5</b></a>, <a class="iref" href="#rfc.xref.header.vary.2">5.1</a></li> 
    1802                         <li class="indline1">Warning&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.warning.1">2.3.3</a>, <a class="iref" href="#rfc.xref.header.warning.2">2.4</a>, <a class="iref" href="#rfc.xref.header.warning.3">2.7</a>, <a class="iref" href="#rfc.iref.h.7"><b>3.6</b></a>, <a class="iref" href="#rfc.xref.header.warning.4">5.1</a>, <a class="iref" href="#rfc.xref.header.warning.5">A.1</a></li> 
     1806                        <li class="indline1">Warning&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.warning.1">2.3.3</a>, <a class="iref" href="#rfc.xref.header.warning.2">2.7</a>, <a class="iref" href="#rfc.iref.h.7"><b>3.6</b></a>, <a class="iref" href="#rfc.xref.header.warning.3">5.1</a>, <a class="iref" href="#rfc.xref.header.warning.4">A.1</a></li> 
    18031807                     </ul> 
    18041808                  </li> 
     
    18741878                     </ul> 
    18751879                  </li> 
    1876                   <li class="indline1"><em>Part3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.1">2.6</a>, <a class="iref" href="#Part3"><b>8.1</b></a>, <a class="iref" href="#rfc.xref.Part3.2">A.1</a><ul class="ind"> 
    1877                         <li class="indline1"><em>Section 4.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.1">2.6</a></li> 
    1878                      </ul> 
    1879                   </li> 
    1880                   <li class="indline1"><em>Part4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part4.1">2.3.1.1</a>, <a class="iref" href="#rfc.xref.Part4.2">2.4</a>, <a class="iref" href="#Part4"><b>8.1</b></a><ul class="ind"> 
     1880                  <li class="indline1"><em>Part3</em>&nbsp;&nbsp;<a class="iref" href="#Part3"><b>8.1</b></a>, <a class="iref" href="#rfc.xref.Part3.1">A.1</a></li> 
     1881                  <li class="indline1"><em>Part4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part4.1">2.3.1.1</a>, <a class="iref" href="#rfc.xref.Part4.2">2.4</a>, <a class="iref" href="#rfc.xref.Part4.3">2.7</a>, <a class="iref" href="#Part4"><b>8.1</b></a><ul class="ind"> 
     1882                        <li class="indline1"><em>Section 4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part4.3">2.7</a></li> 
    18811883                        <li class="indline1"><em>Section 6.6</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part4.1">2.3.1.1</a></li> 
    18821884                     </ul> 
    18831885                  </li> 
    1884                   <li class="indline1"><em>Part5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part5.1">2.1.1</a>, <a class="iref" href="#rfc.xref.Part5.2">2.1.1</a>, <a class="iref" href="#rfc.xref.Part5.3">2.7</a>, <a class="iref" href="#Part5"><b>8.1</b></a>, <a class="iref" href="#rfc.xref.Part5.4">A.1</a><ul class="ind"> 
    1885                         <li class="indline1"><em>Section 4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part5.2">2.1.1</a>, <a class="iref" href="#rfc.xref.Part5.3">2.7</a></li> 
     1886                  <li class="indline1"><em>Part5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part5.1">2.1.1</a>, <a class="iref" href="#rfc.xref.Part5.2">2.1.1</a>, <a class="iref" href="#Part5"><b>8.1</b></a>, <a class="iref" href="#rfc.xref.Part5.3">A.1</a><ul class="ind"> 
     1887                        <li class="indline1"><em>Section 4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part5.2">2.1.1</a></li> 
    18861888                     </ul> 
    18871889                  </li> 
     
    19351937            </li> 
    19361938            <li class="indline0"><a id="rfc.index.W" href="#rfc.index.W"><b>W</b></a><ul class="ind"> 
    1937                   <li class="indline1">Warning header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.warning.1">2.3.3</a>, <a class="iref" href="#rfc.xref.header.warning.2">2.4</a>, <a class="iref" href="#rfc.xref.header.warning.3">2.7</a>, <a class="iref" href="#rfc.iref.w.1"><b>3.6</b></a>, <a class="iref" href="#rfc.xref.header.warning.4">5.1</a>, <a class="iref" href="#rfc.xref.header.warning.5">A.1</a></li> 
     1939                  <li class="indline1">Warning header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.warning.1">2.3.3</a>, <a class="iref" href="#rfc.xref.header.warning.2">2.7</a>, <a class="iref" href="#rfc.iref.w.1"><b>3.6</b></a>, <a class="iref" href="#rfc.xref.header.warning.3">5.1</a>, <a class="iref" href="#rfc.xref.header.warning.4">A.1</a></li> 
    19381940               </ul> 
    19391941            </li> 
  • 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> 
  • 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.