Changeset 767 for draft-ietf-httpbis/latest/p6-cache.html
- Timestamp:
- 03/03/10 16:14:02 (12 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p6-cache.html
r766 r767 781 781 <p id="rfc.section.2.2.p.2"> <span class="comment" id="TODO-method-cacheability">[<a href="#TODO-method-cacheability" class="smpl">TODO-method-cacheability</a>: define method cacheability for GET, HEAD and POST in p2-semantics.]</span> 782 782 </p> 783 <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.1">[<a href="#rfc.comment.1" class="smpl">rfc.comment.1</a>: DISCUSS: this currently includes successfully validated responses.]</span>783 <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="DISCUSS-includes-validated">[<a href="#DISCUSS-includes-validated" class="smpl">DISCUSS-includes-validated</a>: this currently includes successfully validated responses.]</span> 784 784 </p> 785 785 <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 … … 802 802 </p> 803 803 <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. 804 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.2">[<a href="#rfc.comment.2" class="smpl">rfc.comment.2</a>: This wording may cause confusion, because the response may still be served stale.]</span>804 This means that the response is always stale, so that caches should validate it before using it for subsequent requests. <span class="comment" id="TODO-response-stale">[<a href="#TODO-response-stale" class="smpl">TODO-response-stale</a>: This wording may cause confusion, because the response may still be served stale.]</span> 805 805 </p> 806 806 <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 … … 816 816 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>. 817 817 </p> 818 <p id="rfc.section.2.3.p.8"> <span class="comment" id=" rfc.comment.3">[<a href="#rfc.comment.3" class="smpl">rfc.comment.3</a>: ISSUE: there are not requirements directly applying to cache-request-directives and freshness.]</span>818 <p id="rfc.section.2.3.p.8"> <span class="comment" id="ISSUE-no-req-for-directives">[<a href="#ISSUE-no-req-for-directives" class="smpl">ISSUE-no-req-for-directives</a>: there are not requirements directly applying to cache-request-directives and freshness.]</span> 819 819 </p> 820 820 <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 … … 843 843 <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%. 844 844 </p> 845 <p id="rfc.section.2.3.1.1.p.4"> <span class="comment" id=" rfc.comment.4">[<a href="#rfc.comment.4" class="smpl">rfc.comment.4</a>: REVIEW: took away HTTP/1.0 query string heuristic uncacheability.]</span>845 <p id="rfc.section.2.3.1.1.p.4"> <span class="comment" id="REVIEW-query-string-heuristics">[<a href="#REVIEW-query-string-heuristics" class="smpl">REVIEW-query-string-heuristics</a>: took away HTTP/1.0 query string heuristic uncacheability.]</span> 846 846 </p> 847 847 <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> … … 919 919 </p> 920 920 <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 921 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>921 request is suitable. Instead, the full response is used both to satisfy the request and replace the stored response. <span class="comment" id="TODO-req-missing">[<a href="#TODO-req-missing" class="smpl">TODO-req-missing</a>: Should there be a requirement here?]</span> 922 922 </p> 923 923 <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>). … … 936 936 attacks. 937 937 </p> 938 <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>938 <p id="rfc.section.2.5.p.4"> <span class="comment" id="TODO-def-host-part">[<a href="#TODO-def-host-part" class="smpl">TODO-def-host-part</a>: "host part" needs to be specified better.]</span> 939 939 </p> 940 940 <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. … … 946 946 change at the origin server might not have gone through the cache where a response is stored. 947 947 </p> 948 <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>948 <p id="rfc.section.2.5.p.8"> <span class="comment" id="TODO-spec-success-invalidate">[<a href="#TODO-spec-success-invalidate" class="smpl">TODO-spec-success-invalidate</a>: specify that only successful (2xx, 3xx?) responses invalidate.]</span> 949 949 </p> 950 950 <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> … … 953 953 </p> 954 954 <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 955 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 field955 request can be transformed to the selecting request-headers in the second request by adding or removing linear white space <span class="comment" id="TODO-missing-ref">[<a href="#TODO-missing-ref" class="smpl">TODO-missing-ref</a>: [ref]]</span> at places where this is allowed by the corresponding ABNF, and/or combining multiple message-header fields with the same field 956 956 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>. 957 957 </p> … … 968 968 be used to satisfy the request. 969 969 </p> 970 <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>970 <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="TODO-mention-CL">[<a href="#TODO-mention-CL" class="smpl">TODO-mention-CL</a>: may need language about Content-Location here]</span><span class="comment" id="TODO-inm-mult-etags">[<a href="#TODO-inm-mult-etags" class="smpl">TODO-inm-mult-etags</a>: cover case where INM with multiple etags was sent]</span> 971 971 </p> 972 972 <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. … … 983 983 <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. 984 984 </p> 985 <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.986 </p> 987 <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>985 <p id="rfc.section.2.7.p.6">The updated response can <span class="comment" id="TODO-is-req">[<a href="#TODO-is-req" class="smpl">TODO-is-req</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. 986 </p> 987 <p id="rfc.section.2.7.p.7"> <span class="comment" id="ISSUE-how-head">[<a href="#ISSUE-how-head" class="smpl">ISSUE-how-head</a>: discuss how to handle HEAD updates]</span> 988 988 </p> 989 989 <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="header.fields" href="#header.fields">Header Field Definitions</a></h1> … … 1070 1070 time. If max-stale is assigned a value, then the client is willing to accept a response that has exceeded its expiration time 1071 1071 by no more than the specified number of seconds. If no value is assigned to max-stale, then the client is willing to accept 1072 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></li>1072 a stale response of any age. <span class="comment" id="TODO-staleness">[<a href="#TODO-staleness" class="smpl">TODO-staleness</a>: of any staleness? --mnot]</span></li> 1073 1073 </ul> 1074 1074 <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 … … 1547 1547 <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 1548 1548 for transfer encoding that may not be self delimiting); it was important to straighten out exactly how message lengths are 1549 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>1550 </p> 1551 <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>1549 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="TODO-nonmod">[<a href="#TODO-nonmod" class="smpl">TODO-nonmod</a>: This used to refer to the text about non-modifiable headers, and will have to be updated later on. --jre]</span> 1550 </p> 1551 <p id="rfc.section.A.1.p.3">Proxies should be able to add Content-Length when appropriate. <span class="comment" id="TODO-nonmod2">[<a href="#TODO-nonmod2" class="smpl">TODO-nonmod2</a>: This used to refer to the text about non-modifiable headers, and will have to be updated later on. --jre]</span> 1552 1552 </p> 1553 1553 <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
Note: See TracChangeset
for help on using the changeset viewer.