Changeset 567
- Timestamp:
- 30/03/09 11:29:42 (13 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p6-cache.html
r566 r567 468 468 <tr> 469 469 <td class="header left"></td> 470 <td class="header right">March 27, 2009</td>470 <td class="header right">March 30, 2009</td> 471 471 </tr> 472 472 </table> … … 912 912 <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 913 913 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 914 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="rfc.comment.9">[<a href="#rfc.comment.9" class="smpl">rfc.comment.9</a>: DISCUSS: header-specific canonicalisation]</span> 914 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 915 match after header-specific canonicalization? (see <a href="http://trac.tools.ietf.org/wg/httpbis/trac/ticket/147">Issue 147</a>)]</span> 915 916 </p> 916 917 <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 … … 925 926 <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 926 927 same Request-URI, whose entity-tag differs from that of the existing stored response, and whose Date is more recent than that 927 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. 10">[<a href="#rfc.comment.10" class="smpl">rfc.comment.10</a>: DISCUSS: Not sure if this is necessary.]</span>928 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> 928 929 </p> 929 930 <h2 id="rfc.section.2.7"><a href="#rfc.section.2.7">2.7</a> <a id="combining.headers" href="#combining.headers">Combining Responses</a></h2> … … 948 949 all such old headers <em class="bcp14">MUST</em> be replaced. It <em class="bcp14">MAY</em> store the combined entity-body. 949 950 </p> 950 <p id="rfc.section.2.7.p.5"> <span class="comment" id="rfc.comment.1 1">[<a href="#rfc.comment.11" class="smpl">rfc.comment.11</a>: ISSUE: discuss how to handle HEAD updates]</span>951 <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 952 </p> 952 953 <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="header.fields" href="#header.fields">Header Field Definitions</a></h1> … … 1034 1035 time. If max-stale is assigned a value, then the client is willing to accept a response that has exceeded its expiration time 1035 1036 by no more than the specified number of seconds. If no value is assigned to max-stale, then the client is willing to accept 1036 a stale response of any age. <span class="comment" id="rfc.comment.1 2">[<a href="#rfc.comment.12" class="smpl">rfc.comment.12</a>: of any staleness? --mnot]</span></dd>1037 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> 1037 1038 </dl> 1038 1039 <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 … … 1535 1536 <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 1536 1537 for transfer encoding that may not be self delimiting); it was important to straighten out exactly how message lengths are 1537 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.1 3">[<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>1538 </p> 1539 <p id="rfc.section.A.1.p.3">Proxies should be able to add Content-Length when appropriate. <span class="comment" id="rfc.comment.1 4">[<a href="#rfc.comment.14" class="smpl">rfc.comment.14</a>: This used to refer to the text about non-modifiable headers, and will have to be updated later on. --jre]</span>1538 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> 1539 </p> 1540 <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> 1540 1541 </p> 1541 1542 <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 -
draft-ietf-httpbis/latest/p6-cache.xml
r562 r567 797 797 <cref>[ref]</cref> at places where this is allowed by the corresponding ABNF, and/or 798 798 combining multiple message-header fields with the same field name following the rules 799 about message headers in &message-headers;. <cref>DISCUSS: header-specific canonicalisation</cref> 799 about message headers in &message-headers;. <cref anchor="DISCUSS-header-specific-canonicalization"> 800 Should the matching requirement be relaxed so that it would be ok to use a cached response 801 if the selecting request headers match after header-specific canonicalization? 802 (see <eref target="http://trac.tools.ietf.org/wg/httpbis/trac/ticket/147">Issue 147</eref>) 803 </cref> 800 804 </t> 801 805 <t>
Note: See TracChangeset
for help on using the changeset viewer.