Changeset 540 for draft-ietf-httpbis/latest/p6-cache.html
- Timestamp:
- 06/03/09 14:08:48 (13 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p6-cache.html
r539 r540 29 29 cite { 30 30 font-style: normal; 31 } 32 div.note { 33 margin-left: 2em; 31 34 } 32 35 dd { … … 465 468 <tr> 466 469 <td class="header left"></td> 467 <td class="header right">March 5, 2009</td>470 <td class="header right">March 6, 2009</td> 468 471 </tr> 469 472 </table> … … 728 731 <li>successfully validated (see <a href="#validation.model" title="Validation Model">Section 2.4</a>). 729 732 </li> 730 </ul> 733 </ul> 731 734 </li> 732 735 </ul> 733 <p id="rfc.section.2.2.p.2"><span class="comment">[rfc.comment.2: TODO: define method cacheability for GET, HEAD and POST in p2-semantics.]</span></p> 734 <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">[rfc.comment.3: DISCUSS: this currently includes successfully validated responses.]</span></p> 736 <p id="rfc.section.2.2.p.2"> <span class="comment">[rfc.comment.2: TODO: define method cacheability for GET, HEAD and POST in p2-semantics.]</span> 737 </p> 738 <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">[rfc.comment.3: DISCUSS: this currently includes successfully validated responses.]</span> 739 </p> 735 740 <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 736 741 the request and having received a corresponding response. … … 752 757 </p> 753 758 <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. 754 This means that the response is always stale, so that caches should validate it before using it for subsequent requests. <span class="comment">[rfc.comment.5: This wording may cause confusion, because the response may still be served stale.]</span></p> 759 This means that the response is always stale, so that caches should validate it before using it for subsequent requests. <span class="comment">[rfc.comment.5: This wording may cause confusion, because the response may still be served stale.]</span> 760 </p> 755 761 <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 756 762 when they are not specified, employing algorithms that use other header values (such as the Last-Modified time) to estimate … … 758 764 on their results. 759 765 </p> 760 < p id="rfc.section.2.3.p.5">The calculation to determine if a response is fresh is:</p>761 < div id="rfc.figure.u.3"></div><pre class="text"> response_is_fresh = (freshness_lifetime > current_age)762 </pre> <p id="rfc.section.2.3.p. 7">The freshness_lifetime is defined in <a href="#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 2.3.1</a>; the current_age is defined in <a href="#age.calculations" title="Calculating Age">Section 2.3.2</a>.763 </p> 764 <p id="rfc.section.2.3.p. 8">Additionally, clients may need to influence freshness calculation. They can do this using several request cache directives,766 <div id="rfc.figure.u.3"></div> 767 <p>The calculation to determine if a response is fresh is:</p> <pre class="text"> response_is_fresh = (freshness_lifetime > current_age) 768 </pre> <p id="rfc.section.2.3.p.6">The freshness_lifetime is defined in <a href="#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 2.3.1</a>; the current_age is defined in <a href="#age.calculations" title="Calculating Age">Section 2.3.2</a>. 769 </p> 770 <p id="rfc.section.2.3.p.7">Additionally, clients may need to influence freshness calculation. They can do this using several request cache directives, 765 771 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>. 766 772 </p> 767 <p id="rfc.section.2.3.p. 9"> <span class="comment">[rfc.comment.6: ISSUE: there are not requirements directly applying to cache-request-directives and freshness.]</span>768 </p> 769 <p id="rfc.section.2.3.p. 10">Note that freshness applies only to cache operation; it cannot be used to force a user agent to refresh its display or reload773 <p id="rfc.section.2.3.p.8"> <span class="comment">[rfc.comment.6: ISSUE: there are not requirements directly applying to cache-request-directives and freshness.]</span> 774 </p> 775 <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 770 776 a resource. See <a href="#history.lists" title="History Lists">Section 4</a> for an explanation of the difference between caches and history mechanisms. 771 777 </p> … … 814 820 <li>age_value, if all of the caches along the response path implement HTTP/1.1.</li> 815 821 </ol> 816 < p id="rfc.section.2.3.2.p.6">These are combined as</p>817 < div id="rfc.figure.u.4"></div><pre class="text"> corrected_received_age = max(now - date_value, age_value)818 </pre> <p id="rfc.section.2.3.2.p.8">When an Age value is received, it <em class="bcp14">MUST</em> be interpreted relative to the time the request was initiated, not the time that the response was received.819 </p> 820 <div id="rfc.figure.u.5"></div> 822 <div id="rfc.figure.u.4"></div> 823 <p>These are combined as</p> <pre class="text"> corrected_received_age = max(now - date_value, age_value) 824 </pre><p id="rfc.section.2.3.2.p.7">When an Age value is received, it <em class="bcp14">MUST</em> be interpreted relative to the time the request was initiated, not the time that the response was received. 825 </p> 826 <div id="rfc.figure.u.5"></div><pre class="text"> corrected_initial_age = corrected_received_age 821 827 + (now - request_time) 822 </pre> <p id="rfc.section.2.3.2.p.10">where "request_time" is the time (according to the local clock) when the request that elicited this response was sent.</p>823 <p id="rfc.section.2.3.2.p.1 1">The current_age of a stored response can then be calculated by adding the amount of time (in seconds) since the stored response828 </pre><p id="rfc.section.2.3.2.p.9">where "request_time" is the time (according to the local clock) when the request that elicited this response was sent.</p> 829 <p id="rfc.section.2.3.2.p.10">The current_age of a stored response can then be calculated by adding the amount of time (in seconds) since the stored response 824 830 was last validated by the origin server to the corrected_initial_age. 825 831 </p> 826 <p id="rfc.section.2.3.2.p.1 2">In summary:</p>827 <div id="rfc.figure.u.6"></div> <pre class="text">age_value - Age header field-value received with the response828 829 830 831 832 833 834 835 836 837 838 839 840 </pre> 832 <p id="rfc.section.2.3.2.p.11">In summary:</p> 833 <div id="rfc.figure.u.6"></div><pre class="text"> age_value - Age header field-value received with the response 834 date_value - Date header field-value received with the response 835 request_time - local time when the cache made the request 836 resulting in the stored response 837 response_time - local time when the cache received the response 838 now - current local time 839 840 apparent_age = max(0, response_time - date_value); 841 corrected_received_age = max(apparent_age, age_value); 842 response_delay = response_time - request_time; 843 corrected_initial_age = corrected_received_age + response_delay; 844 resident_time = now - response_time; 845 current_age = corrected_initial_age + resident_time; 846 </pre><h3 id="rfc.section.2.3.3"><a href="#rfc.section.2.3.3">2.3.3</a> <a id="serving.stale.responses" href="#serving.stale.responses">Serving Stale Responses</a></h3> 841 847 <p id="rfc.section.2.3.3.p.1">A "stale" response is one that either has explicit expiry information, or is allowed to have heuristic expiry calculated, 842 848 but is not fresh according to the calculations in <a href="#expiration.model" title="Freshness Model">Section 2.3</a>. … … 847 853 </p> 848 854 <p id="rfc.section.2.3.3.p.3">Caches <em class="bcp14">SHOULD NOT</em> return stale responses unless they are disconnected (i.e., it cannot contact the origin server or otherwise find a forward 849 path) or otherwise explicitly allowed (e.g., the max-stale request directive; see <a href="#cache-request-directive" title="Request Cache-Control Directives">Section 3.2.1</a>). .855 path) or otherwise explicitly allowed (e.g., the max-stale request directive; see <a href="#cache-request-directive" title="Request Cache-Control Directives">Section 3.2.1</a>). 850 856 </p> 851 857 <p id="rfc.section.2.3.3.p.4">Stale responses <em class="bcp14">SHOULD</em> have a Warning header with the 110 warn-code (see <a href="#header.warning" id="rfc.xref.header.warning.1" title="Warning">Section 3.6</a>). Likewise, the 112 warn-code <em class="bcp14">SHOULD</em> be sent on stale responses if the cache is disconnected. … … 865 871 </p> 866 872 <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 867 the stored response. <span class="comment">[rfc.comment.8: Should there be a requirement here?]</span></p> 873 the stored response. <span class="comment">[rfc.comment.8: Should there be a requirement here?]</span> 874 </p> 868 875 <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>). 869 876 </p> … … 901 908 <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 902 909 request can be transformed to the selecting request-headers in the second request by adding or removing linear white space <span class="comment">[rfc.comment.11: [ref]]</span> at places where this is allowed by the corresponding ABNF, and/or combining multiple message-header fields with the same field 903 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">[rfc.comment.12: DISCUSS: header-specific canonicalisation]</span></p> 910 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">[rfc.comment.12: DISCUSS: header-specific canonicalisation]</span> 911 </p> 904 912 <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 905 913 by the origin server. … … 913 921 <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 914 922 same Request-URI, whose entity-tag differs from that of the existing stored response, and whose Date is more recent than that 915 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">[rfc.comment.13: DISCUSS: Not sure if this is necessary.]</span></p> 923 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">[rfc.comment.13: DISCUSS: Not sure if this is necessary.]</span> 924 </p> 916 925 <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> 917 926 <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 … … 935 944 all such old headers <em class="bcp14">MUST</em> be replaced. It <em class="bcp14">MAY</em> store the combined entity-body. 936 945 </p> 937 <p id="rfc.section.2.7.p.5"><span class="comment">[rfc.comment.14: ISSUE: discuss how to handle HEAD updates]</span></p> 946 <p id="rfc.section.2.7.p.5"> <span class="comment">[rfc.comment.14: ISSUE: discuss how to handle HEAD updates]</span> 947 </p> 938 948 <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="header.fields" href="#header.fields">Header Field Definitions</a></h1> 939 949 <p id="rfc.section.3.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to caching.</p> … … 952 962 <p id="rfc.section.3.1.p.3"> Age field-values are non-negative decimal integers, representing time in seconds.</p> 953 963 </div> 954 <div id="rfc.figure.u.8"></div> 955 </pre> 964 <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.3"></span> <a href="#rule.delta-seconds" class="smpl">delta-seconds</a> = 1*<a href="#notation" class="smpl">DIGIT</a> 965 </pre><p id="rfc.section.3.1.p.5">If a cache receives a value larger than the largest positive integer it can represent, or if any of its age calculations overflows, 956 966 it <em class="bcp14">MUST</em> transmit an Age header with a field-value of 2147483648 (2<sup>31</sup>). Caches <em class="bcp14">SHOULD</em> use an arithmetic type of at least 31 bits of range. 957 967 </p> … … 964 974 <p id="rfc.section.3.2.p.1">The general-header field "Cache-Control" is used to specify directives that <em class="bcp14">MUST</em> be obeyed by all caches along the request/response chain. The directives specify behavior intended to prevent caches from 965 975 adversely interfering with the request or response. Cache directives are unidirectional in that the presence of a directive 966 in a request does not imply that the same directive is to be given in the response. 967 </p> 968 <d l class="empty">969 < dd>Note that HTTP/1.0 caches might not implement Cache-Control and might only implement Pragma: no-cache (see <a href="#header.pragma" id="rfc.xref.header.pragma.2" title="Pragma">Section 3.4</a>).970 </ dd>971 </d l>972 <p id="rfc.section.3.2.p. 2">Cache directives <em class="bcp14">MUST</em> be passed through by a proxy or gateway application, regardless of their significance to that application, since the directives976 in a request does not imply that the same directive is to be given in the response. 977 </p> 978 <div class="note"> 979 <p>Note that HTTP/1.0 caches might not implement Cache-Control and might only implement Pragma: no-cache (see <a href="#header.pragma" id="rfc.xref.header.pragma.2" title="Pragma">Section 3.4</a>). 980 </p> 981 </div> 982 <p id="rfc.section.3.2.p.3">Cache directives <em class="bcp14">MUST</em> be passed through by a proxy or gateway application, regardless of their significance to that application, since the directives 973 983 might be applicable to all recipients along the request/response chain. It is not possible to target a directive to a specific 974 984 cache. … … 982 992 <a href="#header.cache-control" class="smpl">cache-extension</a> = <a href="#core.rules" class="smpl">token</a> [ "=" ( <a href="#core.rules" class="smpl">token</a> / <a href="#core.rules" class="smpl">quoted-string</a> ) ] 983 993 </pre><h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a> <a id="cache-request-directive" href="#cache-request-directive">Request Cache-Control Directives</a></h3> 984 <div id="rfc.figure.u.10"></div> 994 <div id="rfc.figure.u.10"></div><pre class="inline"><span id="rfc.iref.g.7"></span> <a href="#header.cache-control" class="smpl">cache-request-directive</a> = 985 995 "no-cache" 986 996 / "no-store" … … 991 1001 / "only-if-cached" 992 1002 / <a href="#header.cache-control" class="smpl">cache-extension</a> 993 </pre> 1003 </pre><p id="rfc.section.3.2.1.p.2"> <span id="rfc.iref.c.4"></span> <span id="rfc.iref.n.1"></span> no-cache 994 1004 </p> 995 1005 <dl class="empty"> … … 1046 1056 </dl> 1047 1057 <h3 id="rfc.section.3.2.2"><a href="#rfc.section.3.2.2">3.2.2</a> <a id="cache-response-directive" href="#cache-response-directive">Response Cache-Control Directives</a></h3> 1048 <div id="rfc.figure.u.11"></div> 1058 <div id="rfc.figure.u.11"></div><pre class="inline"><span id="rfc.iref.g.8"></span> <a href="#header.cache-control" class="smpl">cache-response-directive</a> = 1049 1059 "public" 1050 1060 / "private" [ "=" <a href="#notation" class="smpl">DQUOTE</a> 1#<a href="#abnf.dependencies" class="smpl">field-name</a> <a href="#notation" class="smpl">DQUOTE</a> ] … … 1057 1067 / "s-maxage" "=" <a href="#rule.delta-seconds" class="smpl">delta-seconds</a> 1058 1068 / <a href="#header.cache-control" class="smpl">cache-extension</a> 1059 </pre> 1069 </pre><p id="rfc.section.3.2.2.p.2"> <span id="rfc.iref.c.11"></span> <span id="rfc.iref.p.1"></span> public 1060 1070 </p> 1061 1071 <dl class="empty"> … … 1154 1164 otherwise private response in their shared cache(s) could do so by including 1155 1165 </p> 1156 <div id="rfc.figure.u.12"></div> 1157 </pre> 1166 <div id="rfc.figure.u.12"></div><pre class="text"> Cache-Control: private, community="UCI" 1167 </pre><p id="rfc.section.3.2.3.p.5">A cache seeing this header field will act correctly even if the cache does not understand the community cache-extension, since 1158 1168 it will also see and understand the private directive and thus default to the safe behavior. 1159 1169 </p> … … 1174 1184 <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.9"></span><span id="rfc.iref.g.10"></span> <a href="#header.expires" class="smpl">Expires</a> = "Expires" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.expires" class="smpl">Expires-v</a> 1175 1185 <a href="#header.expires" class="smpl">Expires-v</a> = <a href="#abnf.dependencies" class="smpl">HTTP-date</a> 1176 </pre><p id="rfc.section.3.3.p.5">For example</p> 1177 <div id="rfc.figure.u.14"></div> <pre class="text"> Expires: Thu, 01 Dec 1994 16:00:00 GMT 1178 </pre> <p id="rfc.section.3.3.p.7"> </p> 1179 <dl class="empty"> 1180 <dd> <b>Note:</b> if a response includes a Cache-Control field with the max-age directive (see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section 3.2.2</a>), that directive overrides the Expires field. Likewise, the s-maxage directive overrides Expires in shared caches. 1181 </dd> 1182 </dl> 1183 <p id="rfc.section.3.3.p.8">HTTP/1.1 servers <em class="bcp14">SHOULD NOT</em> send Expires dates more than one year in the future. 1184 </p> 1185 <p id="rfc.section.3.3.p.9">HTTP/1.1 clients and caches <em class="bcp14">MUST</em> treat other invalid date formats, especially including the value "0", as in the past (i.e., "already expired"). 1186 </pre><div id="rfc.figure.u.14"></div> 1187 <p>For example</p> <pre class="text"> Expires: Thu, 01 Dec 1994 16:00:00 GMT 1188 </pre><div class="note"> 1189 <p> <b>Note:</b> if a response includes a Cache-Control field with the max-age directive (see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section 3.2.2</a>), that directive overrides the Expires field. Likewise, the s-maxage directive overrides Expires in shared caches. 1190 </p> 1191 </div> 1192 <p id="rfc.section.3.3.p.7">HTTP/1.1 servers <em class="bcp14">SHOULD NOT</em> send Expires dates more than one year in the future. 1193 </p> 1194 <p id="rfc.section.3.3.p.8">HTTP/1.1 clients and caches <em class="bcp14">MUST</em> treat other invalid date formats, especially including the value "0", as in the past (i.e., "already expired"). 1186 1195 </p> 1187 1196 <div id="rfc.iref.p.4"></div> … … 1199 1208 has the same semantics as the no-cache response directive (see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section 3.2.2</a>) and is defined here for backward compatibility with HTTP/1.0. Clients <em class="bcp14">SHOULD</em> include both header fields when a no-cache request is sent to a server not known to be HTTP/1.1 compliant. HTTP/1.1 caches <em class="bcp14">SHOULD</em> treat "Pragma: no-cache" as if the client had sent "Cache-Control: no-cache". 1200 1209 </p> 1201 <p id="rfc.section.3.4.p.4"> </p> 1202 <dl class="empty"> 1203 <dd> <b>Note:</b> because the meaning of "Pragma: no-cache" as a response-header field is not actually specified, it does not provide a reliable 1210 <div class="note"> 1211 <p> <b>Note:</b> because the meaning of "Pragma: no-cache" as a response-header field is not actually specified, it does not provide a reliable 1204 1212 replacement for "Cache-Control: no-cache" in a response. 1205 </ dd>1206 </d l>1213 </p> 1214 </div> 1207 1215 <p id="rfc.section.3.4.p.5">This mechanism is deprecated; no new Pragma directives will be defined in HTTP.</p> 1208 1216 <div id="rfc.iref.v.3"></div>
Note: See TracChangeset
for help on using the changeset viewer.