Changeset 691
- Timestamp:
- 11/09/09 09:58:13 (13 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p6-cache.html
r689 r691 398 398 <meta name="DC.Creator" content="Reschke, J. F."> 399 399 <meta name="DC.Identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest"> 400 <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-09- 01">400 <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-09-11"> 401 401 <meta name="DC.Relation.Replaces" content="urn:ietf:rfc:2616"> 402 402 <meta name="DC.Description.Abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This document is Part 6 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 6 defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages."> … … 430 430 </tr> 431 431 <tr> 432 <td class="header left">Expires: March 5, 2010</td>432 <td class="header left">Expires: March 15, 2010</td> 433 433 <td class="header right">HP</td> 434 434 </tr> … … 487 487 <tr> 488 488 <td class="header left"></td> 489 <td class="header right">September 1 , 2009</td>489 <td class="header right">September 11, 2009</td> 490 490 </tr> 491 491 </table> … … 511 511 <p>The list of Internet-Draft Shadow Directories can be accessed at <<a href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a>>. 512 512 </p> 513 <p>This Internet-Draft will expire in March 5, 2010.</p>513 <p>This Internet-Draft will expire in March 15, 2010.</p> 514 514 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 515 515 <p>Copyright © 2009 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 902 902 <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 2.3.3</a>). 903 903 </p> 904 <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 the905 same Request-URI, whose entity-tag differs from that of the existing stored response, and whose Date is more recent than that906 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>907 </p>908 904 <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a> <a id="invalidation.after.updates.or.deletions" href="#invalidation.after.updates.or.deletions">Request Methods that Invalidate</a></h2> 909 905 <p id="rfc.section.2.5.p.1">Because unsafe methods (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 7.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) have the potential for changing state on the origin server, intervening caches can use them to keep their contents up-to-date. … … 919 915 attacks. 920 916 </p> 921 <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>917 <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> 922 918 </p> 923 919 <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. … … 929 925 change at the origin server might not have gone through the cache where a response is stored. 930 926 </p> 931 <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>927 <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> 932 928 </p> 933 929 <h2 id="rfc.section.2.6"><a href="#rfc.section.2.6">2.6</a> <a id="caching.negotiated.responses" href="#caching.negotiated.responses">Caching Negotiated Responses</a></h2> … … 936 932 </p> 937 933 <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 938 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 field934 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 939 935 name following the rules about header fields in <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.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>. 940 936 </p> … … 951 947 be used to satisfy the request. 952 948 </p> 953 <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>949 <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.9">[<a href="#rfc.comment.9" class="smpl">rfc.comment.9</a>: may need language about Content-Location here]</span><span class="comment" id="rfc.comment.10">[<a href="#rfc.comment.10" class="smpl">rfc.comment.10</a>: cover case where INM with multiple etags was sent]</span> 954 950 </p> 955 951 <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 validators, and those validators <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. … … 966 962 <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. 967 963 </p> 968 <p id="rfc.section.2.7.p.6">The updated response can [[<span class="comment" id="rfc.comment.1 2">[<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.969 </p> 970 <p id="rfc.section.2.7.p.7"> <span class="comment" id="rfc.comment.1 3">[<a href="#rfc.comment.13" class="smpl">rfc.comment.13</a>: ISSUE: discuss how to handle HEAD updates]</span>964 <p id="rfc.section.2.7.p.6">The updated response can [[<span class="comment" id="rfc.comment.11">[<a href="#rfc.comment.11" class="smpl">rfc.comment.11</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. 965 </p> 966 <p id="rfc.section.2.7.p.7"> <span class="comment" id="rfc.comment.12">[<a href="#rfc.comment.12" class="smpl">rfc.comment.12</a>: ISSUE: discuss how to handle HEAD updates]</span> 971 967 </p> 972 968 <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="header.fields" href="#header.fields">Header Field Definitions</a></h1> … … 1054 1050 time. If max-stale is assigned a value, then the client is willing to accept a response that has exceeded its expiration time 1055 1051 by no more than the specified number of seconds. If no value is assigned to max-stale, then the client is willing to accept 1056 a stale response of any age. <span class="comment" id="rfc.comment.1 4">[<a href="#rfc.comment.14" class="smpl">rfc.comment.14</a>: of any staleness? --mnot]</span></dd>1052 a stale response of any age. <span class="comment" id="rfc.comment.13">[<a href="#rfc.comment.13" class="smpl">rfc.comment.13</a>: of any staleness? --mnot]</span></dd> 1057 1053 </dl> 1058 1054 <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 … … 1537 1533 <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 1538 1534 for transfer encoding that may not be self delimiting); it was important to straighten out exactly how message lengths are 1539 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.1 5">[<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>1540 </p> 1541 <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 6">[<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>1535 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.14">[<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> 1536 </p> 1537 <p id="rfc.section.A.1.p.3">Proxies should be able to add Content-Length when appropriate. <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> 1542 1538 </p> 1543 1539 <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 … … 1549 1545 </p> 1550 1546 <h2 id="rfc.section.A.2"><a href="#rfc.section.A.2">A.2</a> <a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2> 1551 <p id="rfc.section.A.2.p.1">Clarify denial of service attack avoidance requirement. (<a href="#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section 2.5</a>) 1552 </p> 1553 <p id="rfc.section.A.2.p.2">Do not mention RFC 2047 encoding and multiple languages in Warning headers anymore, as these aspects never were implemented. 1547 <p id="rfc.section.A.2.p.1">Remove requirement to consider Content-Location in successful responses in order to determine the appropriate response to 1548 use. (<a href="#validation.model" title="Validation Model">Section 2.4</a>) 1549 </p> 1550 <p id="rfc.section.A.2.p.2">Clarify denial of service attack avoidance requirement. (<a href="#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section 2.5</a>) 1551 </p> 1552 <p id="rfc.section.A.2.p.3">Do not mention RFC 2047 encoding and multiple languages in Warning headers anymore, as these aspects never were implemented. 1554 1553 (<a href="#header.warning" id="rfc.xref.header.warning.5" title="Warning">Section 3.6</a>) 1555 1554 </p> … … 1721 1720 <p id="rfc.section.C.9.p.1">Closed issues: </p> 1722 1721 <ul> 1722 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/167">http://tools.ietf.org/wg/httpbis/trac/ticket/167</a>>: "Content-Location on 304 responses" 1723 </li> 1723 1724 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/187">http://tools.ietf.org/wg/httpbis/trac/ticket/187</a>>: "RFC2047 and warn-text" 1724 1725 </li> -
draft-ietf-httpbis/latest/p6-cache.xml
r689 r691 756 756 target="serving.stale.responses" />). 757 757 </t> 758 <t>759 If a cache receives a successful response whose Content-Location field760 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, the763 existing response &SHOULD-NOT; be returned in response to future764 requests and &SHOULD; be deleted from the cache. <cref>DISCUSS: Not765 sure if this is necessary.</cref>766 </t>767 758 </section> 768 759 … … 2070 2061 <section anchor="changes.from.rfc.2616" title="Changes from RFC 2616"> 2071 2062 <t> 2063 Remove requirement to consider Content-Location in successful responses 2064 in order to determine the appropriate response to use. 2065 (<xref target="validation.model" />) 2066 </t> 2067 <t> 2072 2068 Clarify denial of service attack avoidance requirement. 2073 2069 (<xref target="invalidation.after.updates.or.deletions" />) … … 2309 2305 <list style="symbols"> 2310 2306 <t> 2307 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/167"/>: 2308 "Content-Location on 304 responses" 2309 </t> 2310 <t> 2311 2311 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/187"/>: 2312 2312 "RFC2047 and warn-text"
Note: See TracChangeset
for help on using the changeset viewer.