Changeset 561
- Timestamp:
- 12/03/09 12:14:29 (13 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p6-cache.html
r560 r561 719 719 </p> 720 720 <ul> 721 <li>The presented Request-URI and that of the stored response match (see <span class="comment" id="rfc.comment.1">[<a href="#rfc.comment.1" class="smpl">rfc.comment.1</a>: TBD]</span>), and 721 <li>The presented Request-URI and that of the stored response match (<span class="comment" id="TODO-Request-URI">[<a href="#TODO-Request-URI" class="smpl">TODO-Request-URI</a>: Need to find a new term for this, as Part 1 doesn't define Request-URI anymore; the new term request-target does not work 722 for this.]</span>), and 722 723 </li> 723 724 <li>the request method associated with the stored response allows it to be used for the presented request, and</li> … … 737 738 </li> 738 739 </ul> 739 <p id="rfc.section.2.2.p.2"> <span class="comment" id="rfc.comment. 2">[<a href="#rfc.comment.2" class="smpl">rfc.comment.2</a>: TODO: define method cacheability for GET, HEAD and POST in p2-semantics.]</span>740 </p> 741 <p id="rfc.section.2.2.p.3">When a stored response is used to satisfy a request, caches <em class="bcp14">MUST</em> include a single Age header field <a href="#header.age" id="rfc.xref.header.age.1" title="Age">Section 3.1</a> in the response with a value equal to the stored response's current_age; see <a href="#age.calculations" title="Calculating Age">Section 2.3.2</a>. <span class="comment" id="rfc.comment. 3">[<a href="#rfc.comment.3" class="smpl">rfc.comment.3</a>: DISCUSS: this currently includes successfully validated responses.]</span>740 <p id="rfc.section.2.2.p.2"> <span class="comment" id="rfc.comment.1">[<a href="#rfc.comment.1" class="smpl">rfc.comment.1</a>: TODO: define method cacheability for GET, HEAD and POST in p2-semantics.]</span> 741 </p> 742 <p id="rfc.section.2.2.p.3">When a stored response is used to satisfy a request, caches <em class="bcp14">MUST</em> include a single Age header field <a href="#header.age" id="rfc.xref.header.age.1" title="Age">Section 3.1</a> in the response with a value equal to the stored response's current_age; see <a href="#age.calculations" title="Calculating Age">Section 2.3.2</a>. <span class="comment" id="rfc.comment.2">[<a href="#rfc.comment.2" class="smpl">rfc.comment.2</a>: DISCUSS: this currently includes successfully validated responses.]</span> 742 743 </p> 743 744 <p id="rfc.section.2.2.p.4">Requests with methods that are unsafe (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 7.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) <em class="bcp14">MUST</em> be written through the cache to the origin server; i.e., A cache must not reply to such a request before having forwarded … … 749 750 forward a request with "Cache-Control: max-age=0" or "Cache-Control: no-cache" to disambiguate which response to use. 750 751 </p> 751 <p id="rfc.section.2.2.p.7"> <span class="comment" id="rfc.comment. 4">[<a href="#rfc.comment.4" class="smpl">rfc.comment.4</a>: TODO: end-to-end and hop-by-hop headers, non-modifiable headers removed; re-spec in p1]</span>752 <p id="rfc.section.2.2.p.7"> <span class="comment" id="rfc.comment.3">[<a href="#rfc.comment.3" class="smpl">rfc.comment.3</a>: TODO: end-to-end and hop-by-hop headers, non-modifiable headers removed; re-spec in p1]</span> 752 753 </p> 753 754 <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a> <a id="expiration.model" href="#expiration.model">Freshness Model</a></h2> … … 760 761 </p> 761 762 <p id="rfc.section.2.3.p.3">If an origin server wishes to force a cache to validate every request, it can assign an explicit expiration time in the past. 762 This means that the response is always stale, so that caches should validate it before using it for subsequent requests. <span class="comment" id="rfc.comment. 5">[<a href="#rfc.comment.5" class="smpl">rfc.comment.5</a>: This wording may cause confusion, because the response may still be served stale.]</span>763 This means that the response is always stale, so that caches should validate it before using it for subsequent requests. <span class="comment" id="rfc.comment.4">[<a href="#rfc.comment.4" class="smpl">rfc.comment.4</a>: This wording may cause confusion, because the response may still be served stale.]</span> 763 764 </p> 764 765 <p id="rfc.section.2.3.p.4">Since origin servers do not always provide explicit expiration times, HTTP caches may also assign heuristic expiration times … … 774 775 with the effect of either increasing or loosening constraints on freshness. See <a href="#cache-request-directive" title="Request Cache-Control Directives">Section 3.2.1</a>. 775 776 </p> 776 <p id="rfc.section.2.3.p.8"> <span class="comment" id="rfc.comment. 6">[<a href="#rfc.comment.6" class="smpl">rfc.comment.6</a>: ISSUE: there are not requirements directly applying to cache-request-directives and freshness.]</span>777 <p id="rfc.section.2.3.p.8"> <span class="comment" id="rfc.comment.5">[<a href="#rfc.comment.5" class="smpl">rfc.comment.5</a>: ISSUE: there are not requirements directly applying to cache-request-directives and freshness.]</span> 777 778 </p> 778 779 <p id="rfc.section.2.3.p.9">Note that freshness applies only to cache operation; it cannot be used to force a user agent to refresh its display or reload … … 801 802 <p id="rfc.section.2.3.1.1.p.3">Also, if the response has a Last-Modified header (<a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 6.6</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>), the heuristic expiration value <em class="bcp14">SHOULD</em> be no more than some fraction of the interval since that time. A typical setting of this fraction might be 10%. 802 803 </p> 803 <p id="rfc.section.2.3.1.1.p.4"> <span class="comment" id="rfc.comment. 7">[<a href="#rfc.comment.7" class="smpl">rfc.comment.7</a>: REVIEW: took away HTTP/1.0 query string heuristic uncacheability.]</span>804 <p id="rfc.section.2.3.1.1.p.4"> <span class="comment" id="rfc.comment.6">[<a href="#rfc.comment.6" class="smpl">rfc.comment.6</a>: REVIEW: took away HTTP/1.0 query string heuristic uncacheability.]</span> 804 805 </p> 805 806 <h3 id="rfc.section.2.3.2"><a href="#rfc.section.2.3.2">2.3.2</a> <a id="age.calculations" href="#age.calculations">Calculating Age</a></h3> … … 874 875 </p> 875 876 <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 876 the stored response. <span class="comment" id="rfc.comment. 8">[<a href="#rfc.comment.8" class="smpl">rfc.comment.8</a>: Should there be a requirement here?]</span>877 the stored response. <span class="comment" id="rfc.comment.7">[<a href="#rfc.comment.7" class="smpl">rfc.comment.7</a>: Should there be a requirement here?]</span> 877 878 </p> 878 879 <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 3.6</a>) unless the stored response includes the "must-revalidate" cache directive (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section 2.3.3</a>). … … 891 892 attacks. 892 893 </p> 893 <p id="rfc.section.2.5.p.4"> <span class="comment" id="rfc.comment. 9">[<a href="#rfc.comment.9" class="smpl">rfc.comment.9</a>: TODO: "host part" needs to be specified better.]</span>894 <p id="rfc.section.2.5.p.4"> <span class="comment" id="rfc.comment.8">[<a href="#rfc.comment.8" class="smpl">rfc.comment.8</a>: TODO: "host part" needs to be specified better.]</span> 894 895 </p> 895 896 <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. … … 901 902 change at the origin server might not have gone through the cache where a response is stored. 902 903 </p> 903 <p id="rfc.section.2.5.p.8"> <span class="comment" id="rfc.comment. 10">[<a href="#rfc.comment.10" class="smpl">rfc.comment.10</a>: TODO: specify that only successful (2xx, 3xx?) responses invalidate.]</span>904 <p id="rfc.section.2.5.p.8"> <span class="comment" id="rfc.comment.9">[<a href="#rfc.comment.9" class="smpl">rfc.comment.9</a>: TODO: specify that only successful (2xx, 3xx?) responses invalidate.]</span> 904 905 </p> 905 906 <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> … … 910 911 </p> 911 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 912 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.1 1">[<a href="#rfc.comment.11" class="smpl">rfc.comment.11</a>: [ref]]</span> at places where this is allowed by the corresponding ABNF, and/or combining multiple message-header fields with the same field913 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.1 2">[<a href="#rfc.comment.12" class="smpl">rfc.comment.12</a>: DISCUSS: header-specific canonicalisation]</span>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.10">[<a href="#rfc.comment.10" class="smpl">rfc.comment.10</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.11">[<a href="#rfc.comment.11" class="smpl">rfc.comment.11</a>: DISCUSS: header-specific canonicalisation]</span> 914 915 </p> 915 916 <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 … … 924 925 <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 925 926 same Request-URI, whose entity-tag differs from that of the existing stored response, and whose Date is more recent than that 926 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.1 3">[<a href="#rfc.comment.13" class="smpl">rfc.comment.13</a>: DISCUSS: Not sure if this is necessary.]</span>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.12">[<a href="#rfc.comment.12" class="smpl">rfc.comment.12</a>: DISCUSS: Not sure if this is necessary.]</span> 927 928 </p> 928 929 <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> … … 947 948 all such old headers <em class="bcp14">MUST</em> be replaced. It <em class="bcp14">MAY</em> store the combined entity-body. 948 949 </p> 949 <p id="rfc.section.2.7.p.5"> <span class="comment" id="rfc.comment.1 4">[<a href="#rfc.comment.14" class="smpl">rfc.comment.14</a>: ISSUE: discuss how to handle HEAD updates]</span>950 <p id="rfc.section.2.7.p.5"> <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> 950 951 </p> 951 952 <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="header.fields" href="#header.fields">Header Field Definitions</a></h1> … … 1033 1034 time. If max-stale is assigned a value, then the client is willing to accept a response that has exceeded its expiration time 1034 1035 by no more than the specified number of seconds. If no value is assigned to max-stale, then the client is willing to accept 1035 a stale response of any age. <span class="comment" id="rfc.comment.1 5">[<a href="#rfc.comment.15" class="smpl">rfc.comment.15</a>: of any staleness? --mnot]</span></dd>1036 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> 1036 1037 </dl> 1037 1038 <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 … … 1534 1535 <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 1535 1536 for transfer encoding that may not be self delimiting); it was important to straighten out exactly how message lengths are 1536 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 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>1537 </p> 1538 <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 7">[<a href="#rfc.comment.17" class="smpl">rfc.comment.17</a>: This used to refer to the text about non-modifiable headers, and will have to be updated later on. --jre]</span>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.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> 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.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> 1539 1540 </p> 1540 1541 <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
r555 r561 455 455 For a presented request, a cache &MUST-NOT; return a stored response, unless: 456 456 <list style="symbols"> 457 <t>The presented Request-URI and that of the stored response match (see 458 <cref>TBD</cref>), and</t> 457 <t>The presented Request-URI and that of the stored response match 458 (<cref anchor="TODO-Request-URI">Need to find a new term for this, as Part 459 1 doesn't define Request-URI anymore; the new term request-target does not 460 work for this.</cref>), and</t> 459 461 <t>the request method associated with the stored response allows it to be 460 462 used for the presented request, and</t>
Note: See TracChangeset
for help on using the changeset viewer.