Changeset 540 for draft-ietf-httpbis
- Timestamp:
- 06/03/09 14:08:48 (13 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 8 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r538 r540 471 471 <tr> 472 472 <td class="header left"></td> 473 <td class="header right">March 5, 2009</td>473 <td class="header right">March 6, 2009</td> 474 474 </tr> 475 475 </table> -
draft-ietf-httpbis/latest/p2-semantics.html
r538 r540 468 468 <tr> 469 469 <td class="header left"></td> 470 <td class="header right">March 5, 2009</td>470 <td class="header right">March 6, 2009</td> 471 471 </tr> 472 472 </table> -
draft-ietf-httpbis/latest/p3-payload.html
r538 r540 475 475 <tr> 476 476 <td class="header left"></td> 477 <td class="header right">March 5, 2009</td>477 <td class="header right">March 6, 2009</td> 478 478 </tr> 479 479 </table> -
draft-ietf-httpbis/latest/p4-conditional.html
r538 r540 464 464 <tr> 465 465 <td class="header left"></td> 466 <td class="header right">March 5, 2009</td>466 <td class="header right">March 6, 2009</td> 467 467 </tr> 468 468 </table> -
draft-ietf-httpbis/latest/p5-range.html
r532 r540 464 464 <tr> 465 465 <td class="header left"></td> 466 <td class="header right">March 5, 2009</td>466 <td class="header right">March 6, 2009</td> 467 467 </tr> 468 468 </table> -
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> -
draft-ietf-httpbis/latest/p6-cache.xml
r539 r540 1 1 <?xml version="1.0" encoding="utf-8"?> 2 <?xml-stylesheet type='text/xsl' href=' ../myxml2rfc.xslt'?>2 <?xml-stylesheet type='text/xsl' href='rfc2629.xslt'?> 3 3 <!DOCTYPE rfc [ 4 4 <!ENTITY MAY "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MAY</bcp14>"> … … 45 45 <?rfc-ext allow-markup-in-artwork="yes" ?> 46 46 <?rfc-ext include-references-in-index="yes" ?> 47 <?oxygen RNGSchema="../../rfc2629xslt/rfc2629-ext.rnc" type="compact"?>48 47 <rfc category="std" docName="draft-ietf-httpbis-p6-cache-&ID-VERSION;" ipr="pre5378Trust200902" 49 48 obsoletes="2616" x:maturity-level="draft" xmlns:x="http://purl.org/net/xml2rfc/ext"> … … 192 191 <workgroup>HTTPbis Working Group</workgroup> 193 192 194 <abstract> 195 <t>The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, 196 collaborative, hypermedia information systems. This document is Part 6 of the seven-part 197 specification that defines the protocol referred to as "HTTP/1.1" and, taken together, 198 obsoletes RFC 2616. Part 6 defines requirements on HTTP caches and the associated header 199 fields that control cache behavior or indicate cacheable response messages.</t> 200 </abstract> 201 202 <note title="Editorial Note (To be removed by RFC Editor)"> 203 <t>Discussion of this draft should take place on the HTTPBIS working group mailing list 204 (ietf-http-wg@w3.org). The current issues list is at <eref 205 target="http://tools.ietf.org/wg/httpbis/trac/report/11" /> and related documents 206 (including fancy diffs) can be found at <eref target="http://tools.ietf.org/wg/httpbis/" />.</t> 207 <t>The changes in this draft are summarized in <xref target="changes.since.05" />.</t> 208 </note> 193 <abstract> 194 <t> 195 The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, 196 collaborative, hypermedia information systems. This document is Part 6 of the seven-part 197 specification that defines the protocol referred to as "HTTP/1.1" and, taken together, 198 obsoletes RFC 2616. Part 6 defines requirements on HTTP caches and the associated header 199 fields that control cache behavior or indicate cacheable response messages. 200 </t> 201 </abstract> 202 203 <note title="Editorial Note (To be removed by RFC Editor)"> 204 <t> 205 Discussion of this draft should take place on the HTTPBIS working group mailing list 206 (ietf-http-wg@w3.org). The current issues list is at <eref 207 target="http://tools.ietf.org/wg/httpbis/trac/report/11" /> and related documents 208 (including fancy diffs) can be found at <eref target="http://tools.ietf.org/wg/httpbis/" />. 209 </t> 210 <t> 211 The changes in this draft are summarized in <xref target="changes.since.05" />. 212 </t> 213 </note> 214 209 215 </front> 210 216 <middle> 211 <section anchor="caching" title="Introduction"> 212 <t>HTTP is typically used for distributed information systems, where performance can be 213 improved by the use of response caches. This document defines aspects of HTTP/1.1 related to 214 caching and reusing response messages.</t> 215 216 <section anchor="intro.purpose" title="Purpose"> 217 <iref item="cache" /> 218 <t>An HTTP <x:dfn>cache</x:dfn> is a local store of response messages and the subsystem that 219 controls its message storage, retrieval, and deletion. A cache stores cacheable responses 220 in order to reduce the response time and network bandwidth consumption on future, 221 equivalent requests. Any client or server may include a cache, though a cache cannot be 222 used by a server that is acting as a tunnel.</t> 223 <t>Caching would be useless if it did not significantly improve performance. The goal of 224 caching in HTTP/1.1 is to reuse a prior response message to satisfy a current request. In 225 some cases, a stored response can be reused without the need for a network request, 226 reducing latency and network round-trips; a "freshness" mechanism is used for this purpose 227 (see <xref target="expiration.model" />). Even when a new request is required, it is often 228 possible to reuse all or parts of the payload of a prior response to satisfy the request, 229 thereby reducing network bandwidth usage; a "validation" mechanism is used for this 230 purpose (see <xref target="validation.model" />).</t> 231 </section> 232 233 <section anchor="intro.terminology" title="Terminology"> 234 <t>This specification uses a number of terms to refer to the roles played by participants 235 in, and objects of, HTTP caching.</t> 236 <t> 237 <iref item="cacheable" /> 238 <x:dfn>cacheable</x:dfn> 239 <list> 240 <t>A response is cacheable if a cache is allowed to store a copy of the response message 241 for use in answering subsequent requests. Even when a response is cacheable, there may 242 be additional constraints on whether a cache can use the cached copy to satisfy a 243 particular request.</t> 244 </list> 245 </t> 246 <t> 247 <iref item="explicit expiration time" /> 248 <x:dfn>explicit expiration time</x:dfn> 249 <list> 250 <t>The time at which the origin server intends that an entity should no longer be 251 returned by a cache without further validation.</t> 252 </list> 253 </t> 254 <t> 255 <iref item="heuristic expiration time" /> 256 <x:dfn>heuristic expiration time</x:dfn> 257 <list> 258 <t>An expiration time assigned by a cache when no explicit expiration time is 259 available.</t> 260 </list> 261 </t> 262 <t> 263 <iref item="age" /> 264 <x:dfn>age</x:dfn> 265 <list> 266 <t>The age of a response is the time since it was sent by, or successfully validated 267 with, the origin server.</t> 268 </list> 269 </t> 270 <t> 271 <iref item="first-hand" /> 272 <x:dfn>first-hand</x:dfn> 273 <list> 274 <t>A response is first-hand if the freshness model is not in use; i.e., its age is 275 0.</t> 276 </list> 277 </t> 278 <t> 279 <iref item="freshness lifetime" /> 280 <x:dfn>freshness lifetime</x:dfn> 281 <list> 282 <t>The length of time between the generation of a response and its expiration time. </t> 283 </list> 284 </t> 285 <t> 286 <iref item="fresh" /> 287 <x:dfn>fresh</x:dfn> 288 <list> 289 <t>A response is fresh if its age has not yet exceeded its freshness lifetime.</t> 290 </list> 291 </t> 292 <t> 293 <iref item="stale" /> 294 <x:dfn>stale</x:dfn> 295 <list> 296 <t>A response is stale if its age has passed its freshness lifetime (either explicit or heuristic).</t> 297 </list> 298 </t> 299 <t> 300 <iref item="validator" /> 301 <x:dfn>validator</x:dfn> 302 <list> 303 <t>A protocol element (e.g., an entity tag or a Last-Modified time) that is used to find 304 out whether a stored response is an equivalent copy of an entity.</t> 305 </list> 306 </t> 307 <t anchor="shared.and.non-shared.caches"> 308 <iref item="validator" /> 309 <x:dfn>shared cache</x:dfn> 310 <list> 311 <t>A cache that is accessible to more than one user. A non-shared cache is 312 dedicated to a single user.</t> 313 </list> 314 </t> 315 </section> 316 317 318 <section anchor="intro.requirements" title="Requirements"> 319 <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 320 NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as 321 described in <xref target="RFC2119" />.</t> 322 <t>An implementation is not compliant if it fails to satisfy one or more of the &MUST; 323 or &REQUIRED; level requirements for the protocols it implements. An implementation 324 that satisfies all the &MUST; or &REQUIRED; level and all the &SHOULD; level 325 requirements for its protocols is said to be "unconditionally compliant"; one that 326 satisfies all the &MUST; level requirements but not all the &SHOULD; level 327 requirements for its protocols is said to be "conditionally compliant."</t> 328 </section> 329 217 218 <section anchor="caching" title="Introduction"> 219 <t> 220 HTTP is typically used for distributed information systems, where performance can be 221 improved by the use of response caches. This document defines aspects of HTTP/1.1 related to 222 caching and reusing response messages. 223 </t> 224 225 <section anchor="intro.purpose" title="Purpose"> 226 <iref item="cache" /> 227 <t> 228 An HTTP <x:dfn>cache</x:dfn> is a local store of response messages and the subsystem that 229 controls its message storage, retrieval, and deletion. A cache stores cacheable responses 230 in order to reduce the response time and network bandwidth consumption on future, 231 equivalent requests. Any client or server may include a cache, though a cache cannot be 232 used by a server that is acting as a tunnel. 233 </t> 234 <t> 235 Caching would be useless if it did not significantly improve performance. The goal of 236 caching in HTTP/1.1 is to reuse a prior response message to satisfy a current request. In 237 some cases, a stored response can be reused without the need for a network request, 238 reducing latency and network round-trips; a "freshness" mechanism is used for this purpose 239 (see <xref target="expiration.model" />). Even when a new request is required, it is often 240 possible to reuse all or parts of the payload of a prior response to satisfy the request, 241 thereby reducing network bandwidth usage; a "validation" mechanism is used for this 242 purpose (see <xref target="validation.model" />). 243 </t> 244 </section> 245 246 <section anchor="intro.terminology" title="Terminology"> 247 <t 248 >This specification uses a number of terms to refer to the roles played by participants 249 in, and objects of, HTTP caching. 250 </t> 251 <t> 252 <iref item="cacheable" /> 253 <x:dfn>cacheable</x:dfn> 254 <list> 255 <t>A response is cacheable if a cache is allowed to store a copy of the response message 256 for use in answering subsequent requests. Even when a response is cacheable, there may 257 be additional constraints on whether a cache can use the cached copy to satisfy a 258 particular request.</t> 259 </list> 260 </t> 261 <t> 262 <iref item="explicit expiration time" /> 263 <x:dfn>explicit expiration time</x:dfn> 264 <list> 265 <t>The time at which the origin server intends that an entity should no longer be 266 returned by a cache without further validation.</t> 267 </list> 268 </t> 269 <t> 270 <iref item="heuristic expiration time" /> 271 <x:dfn>heuristic expiration time</x:dfn> 272 <list> 273 <t>An expiration time assigned by a cache when no explicit expiration time is 274 available.</t> 275 </list> 276 </t> 277 <t> 278 <iref item="age" /> 279 <x:dfn>age</x:dfn> 280 <list> 281 <t>The age of a response is the time since it was sent by, or successfully validated 282 with, the origin server.</t> 283 </list> 284 </t> 285 <t> 286 <iref item="first-hand" /> 287 <x:dfn>first-hand</x:dfn> 288 <list> 289 <t>A response is first-hand if the freshness model is not in use; i.e., its age is 290 0.</t> 291 </list> 292 </t> 293 <t> 294 <iref item="freshness lifetime" /> 295 <x:dfn>freshness lifetime</x:dfn> 296 <list> 297 <t>The length of time between the generation of a response and its expiration time. </t> 298 </list> 299 </t> 300 <t> 301 <iref item="fresh" /> 302 <x:dfn>fresh</x:dfn> 303 <list> 304 <t>A response is fresh if its age has not yet exceeded its freshness lifetime.</t> 305 </list> 306 </t> 307 <t> 308 <iref item="stale" /> 309 <x:dfn>stale</x:dfn> 310 <list> 311 <t>A response is stale if its age has passed its freshness lifetime (either explicit or heuristic).</t> 312 </list> 313 </t> 314 <t> 315 <iref item="validator" /> 316 <x:dfn>validator</x:dfn> 317 <list> 318 <t>A protocol element (e.g., an entity tag or a Last-Modified time) that is used to find 319 out whether a stored response is an equivalent copy of an entity.</t> 320 </list> 321 </t> 322 <t anchor="shared.and.non-shared.caches"> 323 <iref item="validator" /> 324 <x:dfn>shared cache</x:dfn> 325 <list> 326 <t>A cache that is accessible to more than one user. A non-shared cache is 327 dedicated to a single user.</t> 328 </list> 329 </t> 330 </section> 331 332 <section anchor="intro.requirements" title="Requirements"> 333 <t> 334 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 335 NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as 336 described in <xref target="RFC2119" />. 337 </t> 338 <t> 339 An implementation is not compliant if it fails to satisfy one or more of the &MUST; 340 or &REQUIRED; level requirements for the protocols it implements. An implementation 341 that satisfies all the &MUST; or &REQUIRED; level and all the &SHOULD; level 342 requirements for its protocols is said to be "unconditionally compliant"; one that 343 satisfies all the &MUST; level requirements but not all the &SHOULD; level 344 requirements for its protocols is said to be "conditionally compliant." 345 </t> 346 </section> 330 347 331 348 <section title="Syntax Notation" anchor="notation"> … … 386 403 </section> 387 404 388 <section anchor="caching.overview" title="Cache Operation"> 389 390 <section anchor="response.cacheability" title="Response Cacheability"> 391 <t>A cache &MUST-NOT; store a response to any request, unless: <list style="symbols"> 392 <t>The request method is defined as being cacheable, and</t> 393 <t>the "no-store" cache directive (see <xref target="header.cache-control" />) does not 394 appear in request or response headers, and</t> 395 <t>the "private" cache response directive (see <xref target="header.cache-control" /> 396 does not appear in the response, if the cache is shared, and</t> 397 <t>the "Authorization" header (see &header-authorization;) does not appear in the request, if 398 the cache is shared (unless the "public" directive is present; see <xref 399 target="header.cache-control" />), and</t> 400 <t>the cache understands partial responses, if the response is partial or incomplete 401 (see <xref target="errors.or.incomplete.response.cache.behavior" />).</t> 402 </list> 403 </t> 404 <t>Note that in normal operation, most caches will not store a response that has neither a 405 cache validator nor an explicit expiration time, as such responses are not usually 406 useful to store. However, caches are not prohibited from storing such responses.</t> 407 408 <section anchor="errors.or.incomplete.response.cache.behavior" 409 title="Storing Partial and Incomplete Responses"> 410 <t>A cache that receives an incomplete response (for example, with fewer bytes of data 411 than specified in a Content-Length header) can store the response, but &MUST; 412 treat it as a partial response &partial;. Partial responses 413 can be combined as described in &combining-byte-ranges;; the result might be a 414 full response or might still be partial. A cache &MUST-NOT; return a partial 415 response to a client without explicitly marking it as such using the 206 (Partial 416 Content) status code.</t> 417 <t>A cache that does not support the Range and Content-Range headers &MUST-NOT; store 418 incomplete or partial responses.</t> 419 </section> 420 421 </section> 422 423 424 <section anchor="constructing.responses.from.caches" 425 title="Constructing Responses from Caches"> 426 <t>For a presented request, a cache &MUST-NOT; return a stored response, unless: 427 <list style="symbols"> 428 <t>The presented Request-URI and that of the stored response match (see 429 <cref>TBD</cref>), and</t> 430 <t>the request method associated with the stored response allows it to be 431 used for the presented request, and</t> 432 <t>selecting request-headers nominated by the stored response (if any) match those presented (see <xref 433 target="caching.negotiated.responses" />), and</t> 434 <t>the presented request and stored response are free from directives that would prevent 435 its use (see <xref target="header.cache-control" /> and <xref target="header.pragma" 436 />), and</t> 437 <t>the stored response is either: 438 <list style="symbols"> 439 <t>fresh (see <xref target="expiration.model" />), or</t> 440 <t>allowed to be served stale (see <xref target="serving.stale.responses" />), or</t> 441 <t>successfully validated (see <xref target="validation.model" />).</t> 442 </list></t> 443 </list> 444 </t> 445 <t><cref>TODO: define method cacheability for GET, HEAD and POST in p2-semantics.</cref></t> 446 <t>When a stored response is used to satisfy a request, caches &MUST; include a 447 single Age header field <xref target="header.age" /> in the response with a value equal to the stored response's 448 current_age; see <xref target="age.calculations" />. 449 <cref>DISCUSS: this currently includes successfully validated responses.</cref></t> 450 <t>Requests with methods that are unsafe (&safe-methods;) &MUST; be written through the cache to 451 the origin server; i.e., A cache must not reply to such a request before having forwarded the request and having received a 452 corresponding response.</t> 453 <t>Also, note that unsafe requests might invalidate already stored responses; see 454 <xref target="invalidation.after.updates.or.deletions" />.</t> 455 <t>Caches &MUST; use the most recent response (as determined by the Date header) when 456 more than one suitable response is stored. They can also forward a request with 457 "Cache-Control: max-age=0" or "Cache-Control: no-cache" to disambiguate which response to 458 use.</t> 459 <t> 460 <cref>TODO: end-to-end and hop-by-hop headers, non-modifiable headers removed; re-spec in 461 p1</cref> 462 </t> 463 </section> 464 465 466 467 468 <section anchor="expiration.model" title="Freshness Model"> 469 470 <t>When a response is "fresh" in the cache, it can be used to satisfy subsequent 471 requests without contacting the origin server, thereby improving efficiency.</t> 472 <t>The primary mechanism for determining freshness is for an origin server to provide an 473 explicit expiration time in the future, using either the Expires header (<xref 474 target="header.expires" />) or the max-age response cache directive (<xref 475 target="cache-response-directive" />). Generally, origin servers will assign future 476 explicit expiration times to responses in the belief that the entity is not likely to 477 change in a semantically significant way before the expiration time is reached.</t> 478 <t>If an origin server wishes to force a cache to validate every request, it can 479 assign an explicit expiration time in the past. This means that the response is always 480 stale, so that caches should validate it before using it for subsequent requests. <cref>This wording may cause confusion, because the response may still be served stale.</cref></t> 481 <t>Since origin servers do not always provide explicit expiration times, HTTP caches may 482 also assign heuristic expiration times when they are not specified, employing algorithms that 483 use other header values (such as the Last-Modified time) to estimate a plausible 484 expiration time. The HTTP/1.1 specification does not provide specific algorithms, but does 485 impose worst-case constraints on their results.</t> 486 <t>The calculation to determine if a response is fresh is:</t> 487 <figure> 488 <artwork type="code"> 405 <section anchor="caching.overview" title="Cache Operation"> 406 407 <section anchor="response.cacheability" title="Response Cacheability"> 408 <t> 409 A cache &MUST-NOT; store a response to any request, unless: 410 <list style="symbols"> 411 <t>The request method is defined as being cacheable, and</t> 412 <t>the "no-store" cache directive (see <xref target="header.cache-control" />) does not 413 appear in request or response headers, and</t> 414 <t>the "private" cache response directive (see <xref target="header.cache-control" /> 415 does not appear in the response, if the cache is shared, and</t> 416 <t>the "Authorization" header (see &header-authorization;) does not appear in the request, if 417 the cache is shared (unless the "public" directive is present; see <xref 418 target="header.cache-control" />), and</t> 419 <t>the cache understands partial responses, if the response is partial or incomplete 420 (see <xref target="errors.or.incomplete.response.cache.behavior" />).</t> 421 </list> 422 </t> 423 <t> 424 Note that in normal operation, most caches will not store a response that has neither a 425 cache validator nor an explicit expiration time, as such responses are not usually 426 useful to store. However, caches are not prohibited from storing such responses. 427 </t> 428 429 <section anchor="errors.or.incomplete.response.cache.behavior" title="Storing Partial and Incomplete Responses"> 430 <t> 431 A cache that receives an incomplete response (for example, with fewer bytes of data 432 than specified in a Content-Length header) can store the response, but &MUST; 433 treat it as a partial response &partial;. Partial responses 434 can be combined as described in &combining-byte-ranges;; the result might be a 435 full response or might still be partial. A cache &MUST-NOT; return a partial 436 response to a client without explicitly marking it as such using the 206 (Partial 437 Content) status code. 438 </t> 439 <t> 440 A cache that does not support the Range and Content-Range headers &MUST-NOT; store 441 incomplete or partial responses. 442 </t> 443 </section> 444 445 </section> 446 447 448 <section anchor="constructing.responses.from.caches" title="Constructing Responses from Caches"> 449 <t> 450 For a presented request, a cache &MUST-NOT; return a stored response, unless: 451 <list style="symbols"> 452 <t>The presented Request-URI and that of the stored response match (see 453 <cref>TBD</cref>), and</t> 454 <t>the request method associated with the stored response allows it to be 455 used for the presented request, and</t> 456 <t>selecting request-headers nominated by the stored response (if any) match those presented (see <xref 457 target="caching.negotiated.responses" />), and</t> 458 <t>the presented request and stored response are free from directives that would prevent 459 its use (see <xref target="header.cache-control" /> and <xref target="header.pragma"/>), 460 and</t> 461 <t>the stored response is either: 462 <list style="symbols"> 463 <t>fresh (see <xref target="expiration.model" />), or</t> 464 <t>allowed to be served stale (see <xref target="serving.stale.responses" />), or</t> 465 <t>successfully validated (see <xref target="validation.model" />).</t> 466 </list> 467 </t> 468 </list> 469 </t> 470 <t> 471 <cref>TODO: define method cacheability for GET, HEAD and POST in p2-semantics.</cref> 472 </t> 473 <t> 474 When a stored response is used to satisfy a request, caches &MUST; include a 475 single Age header field <xref target="header.age" /> in the response with a value equal to the stored response's 476 current_age; see <xref target="age.calculations" />. 477 <cref>DISCUSS: this currently includes successfully validated responses.</cref> 478 </t> 479 <t> 480 Requests with methods that are unsafe (&safe-methods;) &MUST; be written through the cache to 481 the origin server; i.e., A cache must not reply to such a request before having forwarded the request and having received a 482 corresponding response. 483 </t> 484 <t> 485 Also, note that unsafe requests might invalidate already stored responses; see 486 <xref target="invalidation.after.updates.or.deletions" />. 487 </t> 488 <t> 489 Caches &MUST; use the most recent response (as determined by the Date header) when 490 more than one suitable response is stored. They can also forward a request with 491 "Cache-Control: max-age=0" or "Cache-Control: no-cache" to disambiguate which response to 492 use. 493 </t> 494 <t> 495 <cref>TODO: end-to-end and hop-by-hop headers, non-modifiable headers removed; re-spec in p1</cref> 496 </t> 497 </section> 498 499 <section anchor="expiration.model" title="Freshness Model"> 500 <t> 501 When a response is "fresh" in the cache, it can be used to satisfy subsequent 502 requests without contacting the origin server, thereby improving efficiency. 503 </t> 504 <t> 505 The primary mechanism for determining freshness is for an origin server to provide an 506 explicit expiration time in the future, using either the Expires header (<xref 507 target="header.expires" />) or the max-age response cache directive (<xref 508 target="cache-response-directive" />). Generally, origin servers will assign future 509 explicit expiration times to responses in the belief that the entity is not likely to 510 change in a semantically significant way before the expiration time is reached. 511 </t> 512 <t> 513 If an origin server wishes to force a cache to validate every request, it can 514 assign an explicit expiration time in the past. This means that the response is always 515 stale, so that caches should validate it before using it for subsequent requests. 516 <cref>This wording may cause confusion, because the response may still be served stale.</cref> 517 </t> 518 <t> 519 Since origin servers do not always provide explicit expiration times, HTTP caches may 520 also assign heuristic expiration times when they are not specified, employing algorithms that 521 use other header values (such as the Last-Modified time) to estimate a plausible 522 expiration time. The HTTP/1.1 specification does not provide specific algorithms, but does 523 impose worst-case constraints on their results. 524 </t> 525 <figure> 526 <preamble> 527 The calculation to determine if a response is fresh is: 528 </preamble> 529 <artwork type="code"> 489 530 response_is_fresh = (freshness_lifetime > current_age) 490 531 </artwork> 491 </figure> 492 493 <t>The freshness_lifetime is defined in <xref target="calculating.freshness.lifetime" />; 494 the current_age is defined in <xref target="age.calculations" />.</t> 495 <t>Additionally, clients may need to influence freshness calculation. They can do this using 496 several request cache directives, with the effect of either increasing or loosening 497 constraints on freshness. See <xref target="cache-request-directive" />.</t> 498 <t> 499 <cref>ISSUE: there are not requirements directly applying to cache-request-directives and 500 freshness.</cref> 501 </t> 502 <t>Note that freshness applies only to cache operation; it cannot be used to force a user agent 503 to refresh its display or reload a resource. See <xref target="history.lists" /> for an explanation of 504 the difference between caches and history mechanisms.</t> 505 506 <section anchor="calculating.freshness.lifetime" title="Calculating Freshness Lifetime"> 507 <t>A cache can calculate the freshness lifetime (denoted as freshness_lifetime) of a 508 response by using the first match of: <list style="symbols"> 509 <t>If the cache is shared and the s-maxage response cache directive (<xref 510 target="cache-response-directive" />) is present, use its value, or</t> 511 <t>If the max-age response cache directive (<xref target="cache-response-directive" 512 />) is present, use its value, or</t> 513 <t>If the Expires response header (<xref target="header.expires" />) is present, use 514 its value minus the value of the Date response header, or</t> 515 <t>Otherwise, no explicit expiration time is present in the response, but a heuristic 516 may be used; see <xref target="heuristic.freshness" />.</t> 517 </list> 518 </t> 519 <t>Note that this calculation is not vulnerable to clock skew, since all of the 520 information comes from the origin server.</t> 521 522 <section anchor="heuristic.freshness" title="Calculating Heuristic Freshness"> 523 <t>If no explicit expiration time is present in a stored response that has a status code 524 of 200, 203, 206, 300, 301 or 410, a heuristic expiration time can be 525 calculated. Heuristics &MUST-NOT; be used for other response status codes. </t> 526 <t> When a heuristic is used to calculate freshness lifetime, the cache &SHOULD; 527 attach a Warning header with a 113 warn-code to the response if its current_age is 528 more than 24 hours and such a warning is not already present.</t> 529 <t>Also, if the response has a Last-Modified header (&header-last-modified;), the 530 heuristic expiration value &SHOULD; be no more than some fraction of the interval 531 since that time. A typical setting of this fraction might be 10%.</t> 532 <t> 533 <cref>REVIEW: took away HTTP/1.0 query string heuristic uncacheability.</cref> 534 </t> 535 </section> 536 </section> 537 538 <section anchor="age.calculations" title="Calculating Age"> 539 <t>HTTP/1.1 uses the Age response-header to convey the estimated age of the response 540 message when obtained from a cache. The Age field value is the cache's estimate of the 541 amount of time since the response was generated or validated by the origin server. In 542 essence, the Age value is the sum of the time that the response has been resident in 543 each of the caches along the path from the origin server, plus the amount of time it has 544 been in transit along network paths.</t> 545 <t>The term "age_value" denotes the value of the Age header, in a form appropriate for 546 arithmetic operations.</t> 547 <t>HTTP/1.1 requires origin servers to send a Date header, if possible, with every 548 response, giving the time at which the response was generated (see &header-date;). 549 The term "date_value" denotes the value of the Date header, in a form appropriate for 550 arithmetic operations.</t> 551 <t>The term "now" means "the current value of the clock at the host performing the 552 calculation." Hosts that use HTTP, but especially hosts running origin servers and 553 caches, &SHOULD; use NTP <xref target="RFC1305" /> or some similar protocol to 554 synchronize their clocks to a globally accurate time standard.</t> 555 <t>A response's age can be calculated in two entirely independent ways: <list 556 style="numbers"> 557 <t>now minus date_value, if the local clock is reasonably well synchronized to the 558 origin server's clock. If the result is negative, the result is replaced by zero.</t> 559 560 <t>age_value, if all of the caches along the response path implement HTTP/1.1.</t> 561 </list> 562 </t> 563 <t>These are combined as</t> 564 <figure> 565 <artwork type="code"> 532 </figure> 533 534 <t> 535 The freshness_lifetime is defined in <xref target="calculating.freshness.lifetime" />; 536 the current_age is defined in <xref target="age.calculations" />. 537 </t> 538 <t> 539 Additionally, clients may need to influence freshness calculation. They can do this using 540 several request cache directives, with the effect of either increasing or loosening 541 constraints on freshness. See <xref target="cache-request-directive" />. 542 </t> 543 <t> 544 <cref>ISSUE: there are not requirements directly applying to cache-request-directives and 545 freshness.</cref> 546 </t> 547 <t> 548 Note that freshness applies only to cache operation; it cannot be used to force a user agent 549 to refresh its display or reload a resource. See <xref target="history.lists" /> for an explanation of 550 the difference between caches and history mechanisms. 551 </t> 552 553 <section anchor="calculating.freshness.lifetime" title="Calculating Freshness Lifetime"> 554 <t> 555 A cache can calculate the freshness lifetime (denoted as freshness_lifetime) of a 556 response by using the first match of: 557 <list style="symbols"> 558 <t>If the cache is shared and the s-maxage response cache directive (<xref 559 target="cache-response-directive" />) is present, use its value, or</t> 560 <t>If the max-age response cache directive (<xref target="cache-response-directive" 561 />) is present, use its value, or</t> 562 <t>If the Expires response header (<xref target="header.expires" />) is present, use 563 its value minus the value of the Date response header, or</t> 564 <t>Otherwise, no explicit expiration time is present in the response, but a heuristic 565 may be used; see <xref target="heuristic.freshness" />.</t> 566 </list> 567 </t> 568 <t> 569 Note that this calculation is not vulnerable to clock skew, since all of the 570 information comes from the origin server. 571 </t> 572 573 <section anchor="heuristic.freshness" title="Calculating Heuristic Freshness"> 574 <t> 575 If no explicit expiration time is present in a stored response that has a status code 576 of 200, 203, 206, 300, 301 or 410, a heuristic expiration time can be 577 calculated. Heuristics &MUST-NOT; be used for other response status codes. 578 </t> 579 <t> 580 When a heuristic is used to calculate freshness lifetime, the cache &SHOULD; 581 attach a Warning header with a 113 warn-code to the response if its current_age is 582 more than 24 hours and such a warning is not already present. 583 </t> 584 <t> 585 Also, if the response has a Last-Modified header (&header-last-modified;), the 586 heuristic expiration value &SHOULD; be no more than some fraction of the interval 587 since that time. A typical setting of this fraction might be 10%. 588 </t> 589 <t> 590 <cref>REVIEW: took away HTTP/1.0 query string heuristic uncacheability.</cref> 591 </t> 592 </section> 593 </section> 594 595 <section anchor="age.calculations" title="Calculating Age"> 596 <t> 597 HTTP/1.1 uses the Age response-header to convey the estimated age of the response 598 message when obtained from a cache. The Age field value is the cache's estimate of the 599 amount of time since the response was generated or validated by the origin server. In 600 essence, the Age value is the sum of the time that the response has been resident in 601 each of the caches along the path from the origin server, plus the amount of time it has 602 been in transit along network paths. 603 </t> 604 <t> 605 The term "age_value" denotes the value of the Age header, in a form appropriate for 606 arithmetic operations. 607 </t> 608 <t> 609 HTTP/1.1 requires origin servers to send a Date header, if possible, with every 610 response, giving the time at which the response was generated (see &header-date;). 611 The term "date_value" denotes the value of the Date header, in a form appropriate for 612 arithmetic operations. 613 </t> 614 <t> 615 The term "now" means "the current value of the clock at the host performing the 616 calculation." Hosts that use HTTP, but especially hosts running origin servers and 617 caches, &SHOULD; use NTP <xref target="RFC1305" /> or some similar protocol to 618 synchronize their clocks to a globally accurate time standard. 619 </t> 620 <t>A response's age can be calculated in two entirely independent ways: 621 <list style="numbers"> 622 <t>now minus date_value, if the local clock is reasonably well synchronized to the 623 origin server's clock. If the result is negative, the result is replaced by zero.</t> 624 <t>age_value, if all of the caches along the response path implement HTTP/1.1.</t> 625 </list> 626 </t> 627 <figure> 628 <preamble>These are combined as</preamble> 629 <artwork type="code"> 566 630 corrected_received_age = max(now - date_value, age_value) 567 </artwork> 568 </figure>569 <t>When an Age value is received, it &MUST; be interpreted relative to the time the570 request was initiated, not the time that the response was received.</t>571 <figure>572 631 </artwork></figure> 632 <t> 633 When an Age value is received, it &MUST; be interpreted relative to the time the 634 request was initiated, not the time that the response was received. 635 </t> 636 <figure><artwork type="code"> 573 637 corrected_initial_age = corrected_received_age 574 638 + (now - request_time) 575 </artwork> 576 </figure> 577 <t>where "request_time" is the time (according to the local clock) when the request that 578 elicited this response was sent.</t> 579 <t>The current_age of a stored response can then be calculated by adding the amount of 580 time (in seconds) since the stored response was last validated by the origin server to 581 the corrected_initial_age.</t> 582 <t>In summary:</t> 583 <figure> 584 <artwork type="code"> 585 age_value - Age header field-value received with the response 586 date_value - Date header field-value received with the response 587 request_time - local time when the cache made the request 588 resulting in the stored response 589 response_time - local time when the cache received the response 590 now - current local time 591 592 apparent_age = max(0, response_time - date_value); 593 corrected_received_age = max(apparent_age, age_value); 594 response_delay = response_time - request_time; 595 corrected_initial_age = corrected_received_age + response_delay; 596 resident_time = now - response_time; 597 current_age = corrected_initial_age + resident_time; 598 </artwork> 599 </figure> 600 </section> 601 602 <section anchor="serving.stale.responses" title="Serving Stale Responses"> 603 <t>A "stale" response is one that either has explicit expiry information, or is allowed to 604 have heuristic expiry calculated, but is not fresh according to the calculations in 605 <xref target="expiration.model" />.</t> 606 <t>Caches &MUST-NOT; return a stale response if it is prohibited by an explicit 607 in-protocol directive (e.g., by a "no-store" or "no-cache" cache directive, a 608 "must-revalidate" cache-response-directive, or an applicable "s-maxage" or 609 "proxy-revalidate" cache-response-directive; see <xref target="cache-response-directive" 610 />). </t> 611 <t>Caches &SHOULD-NOT; return stale responses unless they are 612 disconnected (i.e., it cannot contact the origin server or otherwise find a forward path) 613 or otherwise explicitly allowed (e.g., the max-stale request directive; see <xref target="cache-request-directive" />)..</t> 614 <t>Stale responses &SHOULD; have a Warning header with the 110 warn-code (see <xref 615 target="header.warning" />). Likewise, the 112 warn-code &SHOULD; be sent on stale responses if 616 the cache is disconnected.</t> 617 <t>If a cache receives a first-hand response (either an entire response, or a 304 (Not 618 Modified) response) that it would normally forward to the requesting client, and the 619 received response is no longer fresh, the cache &SHOULD; forward it to the 620 requesting client without adding a new Warning (but without removing any existing 621 Warning headers). A cache &SHOULD-NOT; attempt to validate a response simply because 622 that response became stale in transit.</t> 623 </section> 624 </section> 625 626 627 <section anchor="validation.model" title="Validation Model"> 628 <t>Checking with the origin server to see if a stale or otherwise unusable cached response 629 can be reused is called "validating" or "revalidating." Doing so potentially avoids 630 the overhead of retransmitting the response body when the stored response is valid.</t> 631 <t>HTTP's conditional request mechanism &conditional; is used for this purpose. When a stored 632 response includes one or more validators, such as the field values of an ETag or 633 Last-Modified header field, then a validating request &SHOULD; be made conditional 634 to those field values.</t> 635 <t>A 304 (Not Modified) response status code indicates that the stored 636 response can be updated and reused; see <xref target="combining.headers"/>.</t> 637 <t>If instead the cache receives a full response (i.e., one with a response body), it is used to satisfy the 638 request and replace the stored response. <cref>Should there be a requirement here?</cref></t> 639 <t>If a cache receives a 5xx response while attempting to validate a response, it &MAY; 640 either forward this response to the requesting client, or act as if the server failed to 641 respond. In the latter case, it &MAY; return a previously stored response (which &SHOULD; include the 642 111 warn-code; see <xref target="header.warning"/>) unless the 643 stored response includes the "must-revalidate" cache directive (see <xref 644 target="serving.stale.responses" />).</t> 645 </section> 646 647 <section anchor="invalidation.after.updates.or.deletions" 648 title="Request Methods that Invalidate"> 649 <t>Because unsafe methods (&safe-methods;) have the potential for changing state on the 650 origin server, intervening caches can use them to keep their contents 651 up-to-date.</t> 652 <t>The following HTTP methods &MUST; cause a cache to invalidate the Request-URI as well 653 as the Location and Content-Location headers (if present): <list style="symbols"> 654 <t>PUT</t> 655 <t>DELETE</t> 656 <t>POST</t> 657 </list> 658 </t> 659 <t>An invalidation based on the URI in a Location or Content-Location header &MUST-NOT; 660 be performed if the host part of that URI differs from the host part in the Request-URI. 661 This helps prevent denial of service attacks.</t> 662 <t> 663 <cref>TODO: "host part" needs to be specified better.</cref> 664 </t> 665 <t>A cache that passes through requests for methods it does not understand &SHOULD; 666 invalidate the Request-URI.</t> 667 <t>Here, "invalidate" means that the cache will either remove all stored responses related 668 to the Request-URI, or will mark these as "invalid" and in need of a mandatory validation 669 before they can be returned in response to a subsequent request.</t> 670 <t>Note that this does not guarantee that all appropriate responses are invalidated. For 671 example, the request that caused the change at the origin server might not have gone 672 through the cache where a response is stored.</t> 673 <t> 674 <cref>TODO: specify that only successful (2xx, 3xx?) responses invalidate.</cref> 675 </t> 676 </section> 677 678 679 680 681 682 <section anchor="caching.negotiated.responses" title="Caching Negotiated Responses"> 683 <t>Use of server-driven content negotiation (&server-driven-negotiation;) alters 684 the conditions under which a cache can use the response for subsequent 685 requests.</t> 686 <t>When a cache receives a request that can be satisfied by a stored response 687 that includes a Vary header field (<xref target="header.vary"/>), it &MUST-NOT; use that response unless 688 all of the selecting request-headers in the presented request match the corresponding 689 stored request-headers from the original request.</t> 690 <t>The selecting request-headers from two requests are defined to match if and only if the 691 selecting request-headers in the first request can be transformed to the selecting 692 request-headers in the second request by adding or removing linear white space 693 <cref>[ref]</cref> at places where this is allowed by the corresponding ABNF, and/or 694 combining multiple message-header fields with the same field name following the rules 695 about message headers in &message-headers;. <cref>DISCUSS: header-specific canonicalisation</cref></t> 696 <t>A Vary header field-value of "*" always fails to match, and subsequent requests to that 697 resource can only be properly interpreted by the origin server.</t> 698 <t>If no stored response matches, the cache &MAY; forward the presented request to the origin 699 server in a conditional request, and &SHOULD; include all ETags stored with 700 potentially suitable responses in an If-None-Match request header. If the server responds with 304 (Not Modified) and 701 includes an entity tag or Content-Location that indicates the entity to be used, that 702 cached response &MUST; be used to satisfy the presented request, and &SHOULD; 703 be used to update the corresponding stored response; see <xref target="combining.headers"/>.</t> 704 <t>If any of the stored responses contains only partial content, its entity-tag &SHOULD-NOT; 705 be included in the If-None-Match header field unless the request is for a range that would 706 be fully satisfied by that stored response.</t> 707 <t>If a cache receives a successful response whose Content-Location field matches that of an 708 existing stored response for the same Request-URI, whose entity-tag differs from that of 709 the existing stored response, and whose Date is more recent than that of the existing 710 response, the existing response &SHOULD-NOT; be returned in response to future 711 requests and &SHOULD; be deleted from the cache.<cref>DISCUSS: Not sure if this is necessary.</cref></t> 712 </section> 713 714 715 <section anchor="combining.headers" title="Combining Responses"> 716 <t>When a cache receives a 304 (Not Modified) response or a 206 (Partial Content) response, 717 it needs to update the stored response with the new one, so that the updated response can 718 be sent to the client.</t> 719 <t>If the status code is 304 (Not Modified), the cache &SHOULD; use the stored entity-body as 720 the updated entity-body. If the status code is 206 (Partial Content) and the ETag or 721 Last-Modified headers match exactly, the cache &MAY; combine the stored entity-body in 722 the stored response with the updated entity-body received in the response and use the 723 result as the updated entity-body (see &combining-byte-ranges;).</t> 724 <t>The stored response headers are used for the updated response, except that <list 725 style="symbols"> 726 <t>any stored Warning headers with warn-code 1xx (see <xref target="header.warning" />) 727 &MUST; be deleted from the stored response and the forwarded response.</t> 728 <t>any stored Warning headers with warn-code 2xx &MUST; be retained in the stored 729 response and the forwarded response.</t> 730 <t>any headers provided in the 304 or 206 response &MUST; replace the corresponding 731 headers from the stored response.</t> 732 </list> 733 </t> 734 <t>A cache &MUST; also replace any stored headers with corresponding headers received in the 735 incoming response, except for Warning headers as described immediately above. If a header 736 field-name in the incoming response matches more than one header in the stored response, 737 all such old headers &MUST; be replaced. It &MAY; store the combined 738 entity-body.</t> 739 <t><cref>ISSUE: discuss how to handle HEAD updates</cref></t> 740 </section> 741 742 </section> 743 744 745 746 747 <section anchor="header.fields" title="Header Field Definitions"> 748 <t>This section defines the syntax and semantics of HTTP/1.1 header fields related to caching.</t> 749 <t>For entity-header fields, both sender and recipient refer to either the client or the 750 server, depending on who sends and who receives the entity.</t> 751 752 <section anchor="header.age" title="Age"> 753 <iref item="Age header" primary="true" x:for-anchor="" /> 754 <iref item="Headers" primary="true" subitem="Age" x:for-anchor="" /> 755 <x:anchor-alias value="Age"/> 756 <x:anchor-alias value="Age-v"/> 757 <x:anchor-alias value="age-value"/> 758 <t> The response-header field "Age" conveys the sender's estimate of the amount of time since 759 the response (or its validation) was generated at the origin server. Age values are 760 calculated as specified in <xref target="age.calculations" />.</t> 639 </artwork></figure> 640 <t> 641 where "request_time" is the time (according to the local clock) when the request that 642 elicited this response was sent. 643 </t> 644 <t> 645 The current_age of a stored response can then be calculated by adding the amount of 646 time (in seconds) since the stored response was last validated by the origin server to 647 the corrected_initial_age. 648 </t> 649 <t> 650 In summary: 651 </t> 652 <figure><artwork type="code"> 653 age_value - Age header field-value received with the response 654 date_value - Date header field-value received with the response 655 request_time - local time when the cache made the request 656 resulting in the stored response 657 response_time - local time when the cache received the response 658 now - current local time 659 660 apparent_age = max(0, response_time - date_value); 661 corrected_received_age = max(apparent_age, age_value); 662 response_delay = response_time - request_time; 663 corrected_initial_age = corrected_received_age + response_delay; 664 resident_time = now - response_time; 665 current_age = corrected_initial_age + resident_time; 666 </artwork></figure> 667 </section> 668 669 <section anchor="serving.stale.responses" title="Serving Stale Responses"> 670 <t> 671 A "stale" response is one that either has explicit expiry information, or is allowed to 672 have heuristic expiry calculated, but is not fresh according to the calculations in 673 <xref target="expiration.model" />. 674 </t> 675 <t> 676 Caches &MUST-NOT; return a stale response if it is prohibited by an explicit 677 in-protocol directive (e.g., by a "no-store" or "no-cache" cache directive, a 678 "must-revalidate" cache-response-directive, or an applicable "s-maxage" or 679 "proxy-revalidate" cache-response-directive; see <xref target="cache-response-directive"/>). 680 </t> 681 <t> 682 Caches &SHOULD-NOT; return stale responses unless they are 683 disconnected (i.e., it cannot contact the origin server or otherwise find a forward path) 684 or otherwise explicitly allowed (e.g., the max-stale request directive; see <xref target="cache-request-directive" />). 685 </t> 686 <t> 687 Stale responses &SHOULD; have a Warning header with the 110 warn-code (see <xref 688 target="header.warning" />). Likewise, the 112 warn-code &SHOULD; be sent on stale responses if 689 the cache is disconnected. 690 </t> 691 <t> 692 If a cache receives a first-hand response (either an entire response, or a 304 (Not 693 Modified) response) that it would normally forward to the requesting client, and the 694 received response is no longer fresh, the cache &SHOULD; forward it to the 695 requesting client without adding a new Warning (but without removing any existing 696 Warning headers). A cache &SHOULD-NOT; attempt to validate a response simply because 697 that response became stale in transit. 698 </t> 699 </section> 700 </section> 701 702 <section anchor="validation.model" title="Validation Model"> 703 <t> 704 Checking with the origin server to see if a stale or otherwise unusable cached response 705 can be reused is called "validating" or "revalidating." Doing so potentially avoids 706 the overhead of retransmitting the response body when the stored response is valid. 707 </t> 708 <t> 709 HTTP's conditional request mechanism &conditional; is used for this purpose. When a stored 710 response includes one or more validators, such as the field values of an ETag or 711 Last-Modified header field, then a validating request &SHOULD; be made conditional 712 to those field values. 713 </t> 714 <t> 715 A 304 (Not Modified) response status code indicates that the stored 716 response can be updated and reused; see <xref target="combining.headers"/>. 717 </t> 718 <t> 719 If instead the cache receives a full response (i.e., one with a response body), it is used to satisfy the 720 request and replace the stored response. <cref>Should there be a requirement here?</cref> 721 </t> 722 <t> 723 If a cache receives a 5xx response while attempting to validate a response, it &MAY; 724 either forward this response to the requesting client, or act as if the server failed to 725 respond. In the latter case, it &MAY; return a previously stored response (which &SHOULD; include the 726 111 warn-code; see <xref target="header.warning"/>) unless the 727 stored response includes the "must-revalidate" cache directive (see <xref 728 target="serving.stale.responses" />). 729 </t> 730 </section> 731 732 <section anchor="invalidation.after.updates.or.deletions" title="Request Methods that Invalidate"> 733 <t> 734 Because unsafe methods (&safe-methods;) have the potential for changing state on the 735 origin server, intervening caches can use them to keep their contents 736 up-to-date. 737 </t> 738 <t> 739 The following HTTP methods &MUST; cause a cache to invalidate the Request-URI as well 740 as the Location and Content-Location headers (if present): 741 <list style="symbols"> 742 <t>PUT</t> 743 <t>DELETE</t> 744 <t>POST</t> 745 </list> 746 </t> 747 <t> 748 An invalidation based on the URI in a Location or Content-Location header &MUST-NOT; 749 be performed if the host part of that URI differs from the host part in the Request-URI. 750 This helps prevent denial of service attacks. 751 </t> 752 <t> 753 <cref>TODO: "host part" needs to be specified better.</cref> 754 </t> 755 <t> 756 A cache that passes through requests for methods it does not understand &SHOULD; 757 invalidate the Request-URI. 758 </t> 759 <t> 760 Here, "invalidate" means that the cache will either remove all stored responses related 761 to the Request-URI, or will mark these as "invalid" and in need of a mandatory validation 762 before they can be returned in response to a subsequent request. 763 </t> 764 <t> 765 Note that this does not guarantee that all appropriate responses are invalidated. For 766 example, the request that caused the change at the origin server might not have gone 767 through the cache where a response is stored. 768 </t> 769 <t> 770 <cref>TODO: specify that only successful (2xx, 3xx?) responses invalidate.</cref> 771 </t> 772 </section> 773 774 <section anchor="caching.negotiated.responses" title="Caching Negotiated Responses"> 775 <t> 776 Use of server-driven content negotiation (&server-driven-negotiation;) alters 777 the conditions under which a cache can use the response for subsequent 778 requests. 779 </t> 780 <t> 781 When a cache receives a request that can be satisfied by a stored response 782 that includes a Vary header field (<xref target="header.vary"/>), it &MUST-NOT; use that response unless 783 all of the selecting request-headers in the presented request match the corresponding 784 stored request-headers from the original request. 785 </t> 786 <t> 787 The selecting request-headers from two requests are defined to match if and only if the 788 selecting request-headers in the first request can be transformed to the selecting 789 request-headers in the second request by adding or removing linear white space 790 <cref>[ref]</cref> at places where this is allowed by the corresponding ABNF, and/or 791 combining multiple message-header fields with the same field name following the rules 792 about message headers in &message-headers;. <cref>DISCUSS: header-specific canonicalisation</cref> 793 </t> 794 <t> 795 A Vary header field-value of "*" always fails to match, and subsequent requests to that 796 resource can only be properly interpreted by the origin server. 797 </t> 798 <t> 799 If no stored response matches, the cache &MAY; forward the presented request to the origin 800 server in a conditional request, and &SHOULD; include all ETags stored with 801 potentially suitable responses in an If-None-Match request header. If the server responds with 304 (Not Modified) and 802 includes an entity tag or Content-Location that indicates the entity to be used, that 803 cached response &MUST; be used to satisfy the presented request, and &SHOULD; 804 be used to update the corresponding stored response; see <xref target="combining.headers"/>. 805 </t> 806 <t> 807 If any of the stored responses contains only partial content, its entity-tag &SHOULD-NOT; 808 be included in the If-None-Match header field unless the request is for a range that would 809 be fully satisfied by that stored response. 810 </t> 811 <t> 812 If a cache receives a successful response whose Content-Location field matches that of an 813 existing stored response for the same Request-URI, whose entity-tag differs from that of 814 the existing stored response, and whose Date is more recent than that of the existing 815 response, the existing response &SHOULD-NOT; be returned in response to future 816 requests and &SHOULD; be deleted from the cache.<cref>DISCUSS: Not sure if this is necessary.</cref> 817 </t> 818 </section> 819 820 <section anchor="combining.headers" title="Combining Responses"> 821 <t> 822 When a cache receives a 304 (Not Modified) response or a 206 (Partial Content) response, 823 it needs to update the stored response with the new one, so that the updated response can 824 be sent to the client. 825 </t> 826 <t> 827 If the status code is 304 (Not Modified), the cache &SHOULD; use the stored entity-body as 828 the updated entity-body. If the status code is 206 (Partial Content) and the ETag or 829 Last-Modified headers match exactly, the cache &MAY; combine the stored entity-body in 830 the stored response with the updated entity-body received in the response and use the 831 result as the updated entity-body (see &combining-byte-ranges;). 832 </t> 833 <t> 834 The stored response headers are used for the updated response, except that 835 <list style="symbols"> 836 <t>any stored Warning headers with warn-code 1xx (see <xref target="header.warning" />) 837 &MUST; be deleted from the stored response and the forwarded response.</t> 838 <t>any stored Warning headers with warn-code 2xx &MUST; be retained in the stored 839 response and the forwarded response.</t> 840 <t>any headers provided in the 304 or 206 response &MUST; replace the corresponding 841 headers from the stored response.</t> 842 </list> 843 </t> 844 <t> 845 A cache &MUST; also replace any stored headers with corresponding headers received in the 846 incoming response, except for Warning headers as described immediately above. If a header 847 field-name in the incoming response matches more than one header in the stored response, 848 all such old headers &MUST; be replaced. It &MAY; store the combined 849 entity-body. 850 </t> 851 <t> 852 <cref>ISSUE: discuss how to handle HEAD updates</cref> 853 </t> 854 </section> 855 856 </section> 857 858 <section anchor="header.fields" title="Header Field Definitions"> 859 <t>This section defines the syntax and semantics of HTTP/1.1 header fields related to caching.</t> 860 <t>For entity-header fields, both sender and recipient refer to either the client or the 861 server, depending on who sends and who receives the entity.</t> 862 863 <section anchor="header.age" title="Age"> 864 <iref item="Age header" primary="true" x:for-anchor="" /> 865 <iref item="Headers" primary="true" subitem="Age" x:for-anchor="" /> 866 <x:anchor-alias value="Age"/> 867 <x:anchor-alias value="Age-v"/> 868 <x:anchor-alias value="age-value"/> 869 <t> 870 The response-header field "Age" conveys the sender's estimate of the amount of time since 871 the response (or its validation) was generated at the origin server. Age values are 872 calculated as specified in <xref target="age.calculations" />. 873 </t> 761 874 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Age"/><iref primary="true" item="Grammar" subitem="Age-v"/> 762 875 <x:ref>Age</x:ref> = "Age" ":" <x:ref>OWS</x:ref> <x:ref>Age-v</x:ref> 763 876 <x:ref>Age-v</x:ref> = <x:ref>delta-seconds</x:ref> 764 877 </artwork></figure> 765 766 <x:anchor-alias value="delta-seconds" /> Age field-values are non-negative decimal767 integers, representing time in seconds.</t>768 <figure>769 878 <t anchor="rule.delta-seconds"> 879 <x:anchor-alias value="delta-seconds" /> 880 Age field-values are non-negative decimal integers, representing time in seconds. 881 </t> 882 <figure><artwork type="abnf2616"><iref item="Grammar" primary="true" subitem="delta-seconds" /> 770 883 <x:ref>delta-seconds</x:ref> = 1*<x:ref>DIGIT</x:ref> 771 </artwork> 772 </figure> 773 <t>If a cache receives a value larger than the largest positive integer it can represent, or 774 if any of its age calculations overflows, it &MUST; transmit an Age header with a 775 field-value of 2147483648 (2<x:sup>31</x:sup>). Caches &SHOULD; use an arithmetic type 776 of at least 31 bits of range.</t> 777 <t>The presence of an Age header field in a response implies that a response is not 778 first-hand. However, the converse is not true, since HTTP/1.0 caches may not implement the 779 Age header field.</t> 780 </section> 781 782 <section anchor="header.cache-control" title="Cache-Control"> 783 <iref item="Cache-Control header" primary="true" x:for-anchor="" /> 784 <iref item="Headers" primary="true" subitem="Cache-Control" x:for-anchor="" /> 785 <x:anchor-alias value="Cache-Control"/> 786 <x:anchor-alias value="Cache-Control-v"/> 787 <x:anchor-alias value="cache-directive"/> 788 <x:anchor-alias value="cache-extension"/> 789 <x:anchor-alias value="cache-request-directive"/> 790 <x:anchor-alias value="cache-response-directive"/> 791 <t>The general-header field "Cache-Control" is used to specify directives that &MUST; be 792 obeyed by all caches along the request/response chain. The directives specify behavior 793 intended to prevent caches from adversely interfering with the request or response. Cache 794 directives are unidirectional in that the presence of a directive in a request does not 795 imply that the same directive is to be given in the response. <list> 796 <t>Note that HTTP/1.0 caches might not implement Cache-Control and might only implement 797 Pragma: no-cache (see <xref target="header.pragma" />).</t> 798 </list> 799 </t> 800 <t>Cache directives &MUST; be passed through by a proxy or gateway application, 801 regardless of their significance to that application, since the directives might be 802 applicable to all recipients along the request/response chain. It is not possible to 803 target a directive to a specific cache.</t> 884 </artwork></figure> 885 <t> 886 If a cache receives a value larger than the largest positive integer it can represent, or 887 if any of its age calculations overflows, it &MUST; transmit an Age header with a 888 field-value of 2147483648 (2<x:sup>31</x:sup>). Caches &SHOULD; use an arithmetic type 889 of at least 31 bits of range. 890 </t> 891 <t> 892 The presence of an Age header field in a response implies that a response is not 893 first-hand. However, the converse is not true, since HTTP/1.0 caches may not implement the 894 Age header field. 895 </t> 896 </section> 897 898 <section anchor="header.cache-control" title="Cache-Control"> 899 <iref item="Cache-Control header" primary="true" x:for-anchor="" /> 900 <iref item="Headers" primary="true" subitem="Cache-Control" x:for-anchor="" /> 901 <x:anchor-alias value="Cache-Control"/> 902 <x:anchor-alias value="Cache-Control-v"/> 903 <x:anchor-alias value="cache-directive"/> 904 <x:anchor-alias value="cache-extension"/> 905 <x:anchor-alias value="cache-request-directive"/> 906 <x:anchor-alias value="cache-response-directive"/> 907 <t> 908 The general-header field "Cache-Control" is used to specify directives that &MUST; be 909 obeyed by all caches along the request/response chain. The directives specify behavior 910 intended to prevent caches from adversely interfering with the request or response. Cache 911 directives are unidirectional in that the presence of a directive in a request does not 912 imply that the same directive is to be given in the response. 913 </t> 914 <x:note> 915 <t>Note that HTTP/1.0 caches might not implement Cache-Control and might only implement 916 Pragma: no-cache (see <xref target="header.pragma" />).</t> 917 </x:note> 918 <t> 919 Cache directives &MUST; be passed through by a proxy or gateway application, 920 regardless of their significance to that application, since the directives might be 921 applicable to all recipients along the request/response chain. It is not possible to 922 target a directive to a specific cache. 923 </t> 804 924 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Cache-Control"/><iref primary="true" item="Grammar" subitem="Cache-Control-v"/><iref primary="true" item="Grammar" subitem="cache-extension"/> 805 925 <x:ref>Cache-Control</x:ref> = "Cache-Control" ":" <x:ref>OWS</x:ref> <x:ref>Cache-Control-v</x:ref> … … 812 932 </artwork></figure> 813 933 814 <section anchor="cache-request-directive" title="Request Cache-Control Directives"> 815 <x:anchor-alias value="cache-request-directive" /> 816 817 <figure> 818 <artwork type="abnf2616"><iref item="Grammar" primary="true" subitem="cache-request-directive" /> 934 <section anchor="cache-request-directive" title="Request Cache-Control Directives"> 935 <x:anchor-alias value="cache-request-directive" /> 936 937 <figure><artwork type="abnf2616"><iref item="Grammar" primary="true" subitem="cache-request-directive" /> 819 938 <x:ref>cache-request-directive</x:ref> = 820 939 "no-cache" … … 826 945 / "only-if-cached" 827 946 / <x:ref>cache-extension</x:ref> 828 </artwork> 829 </figure> 830 831 832 <t> 833 <iref item="Cache Directives" primary="true" subitem="no-cache" /> 834 <iref item="no-cache" primary="true" subitem="Cache Directive" /> no-cache <list> 835 <t>The no-cache request directive indicates that a stored response &MUST-NOT; be 836 used to satisfy the request without successful validation on the origin server. </t> 837 </list> 838 </t> 839 <t> 840 <iref item="Cache Directives" primary="true" subitem="no-store" /> 841 <iref item="no-store" primary="true" subitem="Cache Directive" /> no-store <list> 842 <t>The no-store request directive indicates that a cache &MUST-NOT; store any part 843 of either this request or any response to it. This directive applies to both 844 non-shared and shared caches. "&MUST-NOT; store" in this context means that the 845 cache &MUST-NOT; intentionally store the information in non-volatile storage, 846 and &MUST; make a best-effort attempt to remove the information from volatile 847 storage as promptly as possible after forwarding it.</t> 848 <t>This directive is NOT a reliable or sufficient mechanism for ensuring privacy. In 849 particular, malicious or compromised caches might not recognize or obey this 850 directive, and communications networks may be vulnerable to eavesdropping.</t> 851 </list> 852 </t> 853 <t> 854 <iref item="Cache Directives" primary="true" subitem="max-age" /> 855 <iref item="max-age" primary="true" subitem="Cache Directive" /> max-age <list> 856 <t>The max-age request directive indicates that the client is willing to accept a 857 response whose age is no greater than the specified time in seconds. Unless 858 max-stale directive is also included, the client is not willing to accept a stale 859 response.</t> 860 </list> 861 </t> 862 <t> 863 <iref item="Cache Directives" primary="true" subitem="max-stale" /> 864 <iref item="max-stale" primary="true" subitem="Cache Directive" /> max-stale <list> 865 <t>The max-stale request directive indicates that the client is willing to accept a 866 response that has exceeded its expiration time. If max-stale is assigned a value, 867 then the client is willing to accept a response that has exceeded its expiration 868 time by no more than the specified number of seconds. If no value is assigned to 869 max-stale, then the client is willing to accept a stale response of any age. <cref source="mnot">of any staleness?</cref></t> 870 </list> 871 </t> 872 <t> 873 <iref item="Cache Directives" primary="true" subitem="min-fresh" /> 874 <iref item="min-fresh" primary="true" subitem="Cache Directive" /> min-fresh <list> 875 <t>The min-fresh request directive indicates that the client is willing to accept a 876 response whose freshness lifetime is no less than its current age plus the specified 877 time in seconds. That is, the client wants a response that will still be fresh for 878 at least the specified number of seconds.</t> 879 </list> 880 </t> 881 <t> 882 <iref item="Cache Directives" primary="true" subitem="no-transform" /> 883 <iref item="no-transform" primary="true" subitem="Cache Directive" /> no-transform <list> 884 <t>The no-transform request directive indicates that an intermediate cache or proxy 885 &MUST-NOT; change the Content-Encoding, Content-Range or Content-Type request 886 headers, nor the request entity-body.</t> 887 </list> 888 </t> 889 890 <t> 891 <iref item="Cache Directives" primary="true" subitem="only-if-cached" /> 892 <iref item="only-if-cached" primary="true" subitem="Cache Directive" /> only-if-cached <list> 893 <t>The only-if-cached request directive indicates that the client only wishes to 894 return a stored response. If it receives this directive, a cache &SHOULD; either 895 respond using a stored response that is consistent with the other constraints of the 896 request, or respond with a 504 (Gateway Timeout) status. If a group of caches is 897 being operated as a unified system with good internal connectivity, such a request 898 &MAY; be forwarded within that group of caches.</t> 899 </list> 900 </t> 901 </section> 902 903 <section anchor="cache-response-directive" title="Response Cache-Control Directives"> 904 <x:anchor-alias value="cache-response-directive" /> 905 906 <figure> 907 <artwork type="abnf2616"><iref item="Grammar" primary="true" subitem="cache-response-directive" /> 947 </artwork></figure> 948 949 <t> 950 <iref item="Cache Directives" primary="true" subitem="no-cache" /> 951 <iref item="no-cache" primary="true" subitem="Cache Directive" /> 952 no-cache 953 <list> 954 <t>The no-cache request directive indicates that a stored response &MUST-NOT; be 955 used to satisfy the request without successful validation on the origin server.</t> 956 </list> 957 </t> 958 <t> 959 <iref item="Cache Directives" primary="true" subitem="no-store" /> 960 <iref item="no-store" primary="true" subitem="Cache Directive" /> 961 no-store 962 <list> 963 <t>The no-store request directive indicates that a cache &MUST-NOT; store any part 964 of either this request or any response to it. This directive applies to both 965 non-shared and shared caches. "&MUST-NOT; store" in this context means that the 966 cache &MUST-NOT; intentionally store the information in non-volatile storage, 967 and &MUST; make a best-effort attempt to remove the information from volatile 968 storage as promptly as possible after forwarding it.</t> 969 <t>This directive is NOT a reliable or sufficient mechanism for ensuring privacy. In 970 particular, malicious or compromised caches might not recognize or obey this 971 directive, and communications networks may be vulnerable to eavesdropping.</t> 972 </list> 973 </t> 974 <t> 975 <iref item="Cache Directives" primary="true" subitem="max-age" /> 976 <iref item="max-age" primary="true" subitem="Cache Directive" /> 977 max-age 978 <list> 979 <t>The max-age request directive indicates that the client is willing to accept a 980 response whose age is no greater than the specified time in seconds. Unless 981 max-stale directive is also included, the client is not willing to accept a stale 982 response.</t> 983 </list> 984 </t> 985 <t> 986 <iref item="Cache Directives" primary="true" subitem="max-stale" /> 987 <iref item="max-stale" primary="true" subitem="Cache Directive" /> 988 max-stale 989 <list> 990 <t>The max-stale request directive indicates that the client is willing to accept a 991 response that has exceeded its expiration time. If max-stale is assigned a value, 992 then the client is willing to accept a response that has exceeded its expiration 993 time by no more than the specified number of seconds. If no value is assigned to 994 max-stale, then the client is willing to accept a stale response of any age. <cref source="mnot">of any staleness?</cref></t> 995 </list> 996 </t> 997 <t> 998 <iref item="Cache Directives" primary="true" subitem="min-fresh" /> 999 <iref item="min-fresh" primary="true" subitem="Cache Directive" /> 1000 min-fresh 1001 <list> 1002 <t>The min-fresh request directive indicates that the client is willing to accept a 1003 response whose freshness lifetime is no less than its current age plus the specified 1004 time in seconds. That is, the client wants a response that will still be fresh for 1005 at least the specified number of seconds.</t> 1006 </list> 1007 </t> 1008 <t> 1009 <iref item="Cache Directives" primary="true" subitem="no-transform" /> 1010 <iref item="no-transform" primary="true" subitem="Cache Directive" /> 1011 no-transform 1012 <list> 1013 <t>The no-transform request directive indicates that an intermediate cache or proxy 1014 &MUST-NOT; change the Content-Encoding, Content-Range or Content-Type request 1015 headers, nor the request entity-body.</t> 1016 </list> 1017 </t> 1018 <t> 1019 <iref item="Cache Directives" primary="true" subitem="only-if-cached" /> 1020 <iref item="only-if-cached" primary="true" subitem="Cache Directive" /> 1021 only-if-cached 1022 <list> 1023 <t>The only-if-cached request directive indicates that the client only wishes to 1024 return a stored response. If it receives this directive, a cache &SHOULD; either 1025 respond using a stored response that is consistent with the other constraints of the 1026 request, or respond with a 504 (Gateway Timeout) status. If a group of caches is 1027 being operated as a unified system with good internal connectivity, such a request 1028 &MAY; be forwarded within that group of caches.</t> 1029 </list> 1030 </t> 1031 </section> 1032 1033 <section anchor="cache-response-directive" title="Response Cache-Control Directives"> 1034 <x:anchor-alias value="cache-response-directive" /> 1035 1036 <figure><artwork type="abnf2616"><iref item="Grammar" primary="true" subitem="cache-response-directive" /> 908 1037 <x:ref>cache-response-directive</x:ref> = 909 1038 "public" … … 917 1046 / "s-maxage" "=" <x:ref>delta-seconds</x:ref> 918 1047 / <x:ref>cache-extension</x:ref> 919 </artwork> 920 </figure> 921 922 <t> 923 <iref item="Cache Directives" primary="true" subitem="public" /> 924 <iref item="public" primary="true" subitem="Cache Directive" /> public <list> 925 <t>The public response directive indicates that the response &MAY; be cached, even 926 if it would normally be non-cacheable or cacheable only within a non-shared cache. 927 (See also Authorization, &header-authorization;, for additional details.) </t> 928 </list> 929 </t> 930 931 <t> 932 <iref item="Cache Directives" primary="true" subitem="private" /> 933 <iref item="private" primary="true" subitem="Cache Directive" /> private <list> 934 <t>The private response directive indicates that the response message is intended for 935 a single user and &MUST-NOT; be stored by a shared cache. A private (non-shared) 936 cache &MAY; store the response.</t> 937 <t>If the private response directive specifies one or more field-names, this 938 requirement is limited to the field-values associated with the listed response 939 headers. That is, the specified field-names(s) &MUST-NOT; be stored by a shared 940 cache, whereas the remainder of the response message &MAY; be.</t> 941 <t> 942 <x:h>Note:</x:h> This usage of the word private only controls where the response may 943 be stored, and cannot ensure the privacy of the message content.</t> 944 </list> 945 </t> 946 <t> 947 <iref item="Cache Directives" primary="true" subitem="no-cache" /> 948 <iref item="no-cache" primary="true" subitem="Cache Directive" /> no-cache <list> 949 <t>The no-cache response directive indicates that the response &MUST-NOT; be used to 950 satisfy a subsequent request without successful validation on the origin server. 951 This allows an origin server to prevent caching even by caches that have been 952 configured to return stale responses.</t> 953 <t>If the no-cache response directive specifies one or more field-names, this 954 requirement is limited to the field-values assosicated with the listed response 955 headers. That is, the specified field-name(s) &MUST-NOT; be sent in the response 956 to a subsequent request without successful validation on the origin server. This 957 allows an origin server to prevent the re-use of certain header fields in a 958 response, while still allowing caching of the rest of the response.</t> 959 <t> 960 <x:h>Note:</x:h> Most HTTP/1.0 caches will not recognize or obey this directive. 961 </t> 962 </list> 963 </t> 964 965 <t> 966 <iref item="Cache Directives" primary="true" subitem="no-store" /> 967 <iref item="no-store" primary="true" subitem="Cache Directive" /> no-store <list> 968 <t>The no-store response directive indicates that a cache &MUST-NOT; store any 969 part of either the immediate request or response. This directive applies to both 970 non-shared and shared caches. "&MUST-NOT; store" in this context means that the 971 cache &MUST-NOT; intentionally store the information in non-volatile storage, 972 and &MUST; make a best-effort attempt to remove the information from volatile 973 storage as promptly as possible after forwarding it.</t> 974 <t>This directive is NOT a reliable or sufficient mechanism for ensuring privacy. In 975 particular, malicious or compromised caches might not recognize or obey this 976 directive, and communications networks may be vulnerable to eavesdropping.</t> 977 </list> 978 </t> 979 <t> 980 <iref item="Cache Directives" primary="true" subitem="must-revalidate" /> 981 <iref item="must-revalidate" primary="true" subitem="Cache Directive" /> must-revalidate <list> 982 <t>The must-revalidate response directive indicates that once it has become stale, the response &MUST-NOT; be 983 used to satisfy subsequent requests without successful validation on the origin server.</t> 984 <t>The must-revalidate directive is necessary to support reliable operation for 985 certain protocol features. In all circumstances an HTTP/1.1 cache &MUST; obey 986 the must-revalidate directive; in particular, if the cache cannot reach the origin 987 server for any reason, it &MUST; generate a 504 (Gateway Timeout) response.</t> 988 <t>Servers &SHOULD; send the must-revalidate directive if and only if failure to 989 validate a request on the entity could result in incorrect operation, such as a 990 silently unexecuted financial transaction.</t> 991 </list> 992 </t> 993 <t> 994 <iref item="Cache Directives" primary="true" subitem="proxy-revalidate" /> 995 <iref item="proxy-revalidate" primary="true" subitem="Cache Directive" /> 996 proxy-revalidate <list> 997 <t>The proxy-revalidate response directive has the same meaning as the must-revalidate 998 response directive, except that it does not apply to non-shared caches.</t> 999 </list> 1000 </t> 1001 <t> 1002 <iref item="Cache Directives" primary="true" subitem="max-age" /> 1003 <iref item="max-age" primary="true" subitem="Cache Directive" /> max-age <list> 1004 <t>The max-age response directive indicates that response is to be considered stale 1005 after its age is greater than the specified number of seconds.</t> 1006 </list> 1007 </t> 1008 <t> 1009 <iref item="Cache Directives" primary="true" subitem="s-maxage" /> 1010 <iref item="s-maxage" primary="true" subitem="Cache Directive" /> s-maxage <list> 1011 <t>The s-maxage response directive indicates that, in shared caches, the maximum age 1012 specified by this directive overrides the maximum age specified by either the 1013 max-age directive or the Expires header. The s-maxage directive also implies the 1014 semantics of the proxy-revalidate response directive.</t> 1015 </list> 1016 </t> 1017 <t> 1018 <iref item="Cache Directives" primary="true" subitem="no-transform" /> 1019 <iref item="no-transform" primary="true" subitem="Cache Directive" /> no-transform <list> 1020 <t>The no-transform response directive indicates that an intermediate cache or proxy 1021 &MUST-NOT; change the Content-Encoding, Content-Range or Content-Type response 1022 headers, nor the response entity-body.</t> 1023 </list> 1024 </t> 1025 1026 </section> 1027 1028 <section anchor="cache.control.extensions" title="Cache Control Extensions"> 1029 <t>The Cache-Control header field can be extended through the use of one or more 1030 cache-extension tokens, each with an optional value. Informational extensions (those 1031 that do not require a change in cache behavior) can be added without changing the 1032 semantics of other directives. Behavioral extensions are designed to work by acting as 1033 modifiers to the existing base of cache directives. Both the new directive and the 1034 standard directive are supplied, such that applications that do not understand the new 1035 directive will default to the behavior specified by the standard directive, and those 1036 that understand the new directive will recognize it as modifying the requirements 1037 associated with the standard directive. In this way, extensions to the cache-control 1038 directives can be made without requiring changes to the base protocol.</t> 1039 <t>This extension mechanism depends on an HTTP cache obeying all of the cache-control 1040 directives defined for its native HTTP-version, obeying certain extensions, and ignoring 1041 all directives that it does not understand.</t> 1042 <t>For example, consider a hypothetical new response directive called "community" that 1043 acts as a modifier to the private directive. We define this new directive to mean that, 1044 in addition to any non-shared cache, any cache that is shared only by members of the 1045 community named within its value may cache the response. An origin server wishing to 1046 allow the UCI community to use an otherwise private response in their shared cache(s) 1047 could do so by including</t> 1048 <figure> 1049 <artwork type="example"> 1048 </artwork></figure> 1049 1050 <t> 1051 <iref item="Cache Directives" primary="true" subitem="public" /> 1052 <iref item="public" primary="true" subitem="Cache Directive" /> 1053 public 1054 <list> 1055 <t>The public response directive indicates that the response &MAY; be cached, even 1056 if it would normally be non-cacheable or cacheable only within a non-shared cache. 1057 (See also Authorization, &header-authorization;, for additional details.) </t> 1058 </list> 1059 </t> 1060 <t> 1061 <iref item="Cache Directives" primary="true" subitem="private" /> 1062 <iref item="private" primary="true" subitem="Cache Directive" /> 1063 private 1064 <list> 1065 <t>The private response directive indicates that the response message is intended for 1066 a single user and &MUST-NOT; be stored by a shared cache. A private (non-shared) 1067 cache &MAY; store the response.</t> 1068 <t>If the private response directive specifies one or more field-names, this 1069 requirement is limited to the field-values associated with the listed response 1070 headers. That is, the specified field-names(s) &MUST-NOT; be stored by a shared 1071 cache, whereas the remainder of the response message &MAY; be.</t> 1072 <t> 1073 <x:h>Note:</x:h> This usage of the word private only controls where the response may 1074 be stored, and cannot ensure the privacy of the message content.</t> 1075 </list> 1076 </t> 1077 <t> 1078 <iref item="Cache Directives" primary="true" subitem="no-cache" /> 1079 <iref item="no-cache" primary="true" subitem="Cache Directive" /> 1080 no-cache 1081 <list> 1082 <t>The no-cache response directive indicates that the response &MUST-NOT; be used to 1083 satisfy a subsequent request without successful validation on the origin server. 1084 This allows an origin server to prevent caching even by caches that have been 1085 configured to return stale responses.</t> 1086 <t>If the no-cache response directive specifies one or more field-names, this 1087 requirement is limited to the field-values assosicated with the listed response 1088 headers. That is, the specified field-name(s) &MUST-NOT; be sent in the response 1089 to a subsequent request without successful validation on the origin server. This 1090 allows an origin server to prevent the re-use of certain header fields in a 1091 response, while still allowing caching of the rest of the response.</t> 1092 <t> 1093 <x:h>Note:</x:h> Most HTTP/1.0 caches will not recognize or obey this directive. 1094 </t> 1095 </list> 1096 </t> 1097 1098 <t> 1099 <iref item="Cache Directives" primary="true" subitem="no-store" /> 1100 <iref item="no-store" primary="true" subitem="Cache Directive" /> 1101 no-store 1102 <list> 1103 <t>The no-store response directive indicates that a cache &MUST-NOT; store any 1104 part of either the immediate request or response. This directive applies to both 1105 non-shared and shared caches. "&MUST-NOT; store" in this context means that the 1106 cache &MUST-NOT; intentionally store the information in non-volatile storage, 1107 and &MUST; make a best-effort attempt to remove the information from volatile 1108 storage as promptly as possible after forwarding it.</t> 1109 <t>This directive is NOT a reliable or sufficient mechanism for ensuring privacy. In 1110 particular, malicious or compromised caches might not recognize or obey this 1111 directive, and communications networks may be vulnerable to eavesdropping.</t> 1112 </list> 1113 </t> 1114 <t> 1115 <iref item="Cache Directives" primary="true" subitem="must-revalidate" /> 1116 <iref item="must-revalidate" primary="true" subitem="Cache Directive" /> 1117 must-revalidate 1118 <list> 1119 <t>The must-revalidate response directive indicates that once it has become stale, the response &MUST-NOT; be 1120 used to satisfy subsequent requests without successful validation on the origin server.</t> 1121 <t>The must-revalidate directive is necessary to support reliable operation for 1122 certain protocol features. In all circumstances an HTTP/1.1 cache &MUST; obey 1123 the must-revalidate directive; in particular, if the cache cannot reach the origin 1124 server for any reason, it &MUST; generate a 504 (Gateway Timeout) response.</t> 1125 <t>Servers &SHOULD; send the must-revalidate directive if and only if failure to 1126 validate a request on the entity could result in incorrect operation, such as a 1127 silently unexecuted financial transaction.</t> 1128 </list> 1129 </t> 1130 <t> 1131 <iref item="Cache Directives" primary="true" subitem="proxy-revalidate" /> 1132 <iref item="proxy-revalidate" primary="true" subitem="Cache Directive" /> 1133 proxy-revalidate 1134 <list> 1135 <t>The proxy-revalidate response directive has the same meaning as the must-revalidate 1136 response directive, except that it does not apply to non-shared caches.</t> 1137 </list> 1138 </t> 1139 <t> 1140 <iref item="Cache Directives" primary="true" subitem="max-age" /> 1141 <iref item="max-age" primary="true" subitem="Cache Directive" /> 1142 max-age 1143 <list> 1144 <t>The max-age response directive indicates that response is to be considered stale 1145 after its age is greater than the specified number of seconds.</t> 1146 </list> 1147 </t> 1148 <t> 1149 <iref item="Cache Directives" primary="true" subitem="s-maxage" /> 1150 <iref item="s-maxage" primary="true" subitem="Cache Directive" /> 1151 s-maxage 1152 <list> 1153 <t>The s-maxage response directive indicates that, in shared caches, the maximum age 1154 specified by this directive overrides the maximum age specified by either the 1155 max-age directive or the Expires header. The s-maxage directive also implies the 1156 semantics of the proxy-revalidate response directive.</t> 1157 </list> 1158 </t> 1159 <t> 1160 <iref item="Cache Directives" primary="true" subitem="no-transform" /> 1161 <iref item="no-transform" primary="true" subitem="Cache Directive" /> 1162 no-transform 1163 <list> 1164 <t>The no-transform response directive indicates that an intermediate cache or proxy 1165 &MUST-NOT; change the Content-Encoding, Content-Range or Content-Type response 1166 headers, nor the response entity-body.</t> 1167 </list> 1168 </t> 1169 1170 </section> 1171 1172 <section anchor="cache.control.extensions" title="Cache Control Extensions"> 1173 <t> 1174 The Cache-Control header field can be extended through the use of one or more 1175 cache-extension tokens, each with an optional value. Informational extensions (those 1176 that do not require a change in cache behavior) can be added without changing the 1177 semantics of other directives. Behavioral extensions are designed to work by acting as 1178 modifiers to the existing base of cache directives. Both the new directive and the 1179 standard directive are supplied, such that applications that do not understand the new 1180 directive will default to the behavior specified by the standard directive, and those 1181 that understand the new directive will recognize it as modifying the requirements 1182 associated with the standard directive. In this way, extensions to the cache-control 1183 directives can be made without requiring changes to the base protocol. 1184 </t> 1185 <t> 1186 This extension mechanism depends on an HTTP cache obeying all of the cache-control 1187 directives defined for its native HTTP-version, obeying certain extensions, and ignoring 1188 all directives that it does not understand. 1189 </t> 1190 <t> 1191 For example, consider a hypothetical new response directive called "community" that 1192 acts as a modifier to the private directive. We define this new directive to mean that, 1193 in addition to any non-shared cache, any cache that is shared only by members of the 1194 community named within its value may cache the response. An origin server wishing to 1195 allow the UCI community to use an otherwise private response in their shared cache(s) 1196 could do so by including 1197 </t> 1198 <figure><artwork type="example"> 1050 1199 Cache-Control: private, community="UCI" 1051 </artwork> 1052 </figure> 1053 <t>A cache seeing this header field will act correctly even if the cache does not 1054 understand the community cache-extension, since it will also see and understand the 1055 private directive and thus default to the safe behavior.</t> 1056 <t>Unrecognized cache directives &MUST; be ignored; it is assumed that any cache 1057 directive likely to be unrecognized by an HTTP/1.1 cache will be combined with standard 1058 directives (or the response's default cacheability) such that the cache behavior will 1059 remain minimally correct even if the cache does not understand the extension(s).</t> 1060 </section> 1061 1062 </section> 1063 1064 <section anchor="header.expires" title="Expires"> 1065 <iref item="Expires header" primary="true" x:for-anchor="" /> 1066 <iref item="Headers" primary="true" subitem="Expires" x:for-anchor="" /> 1067 <x:anchor-alias value="Expires"/> 1068 <x:anchor-alias value="Expires-v"/> 1069 <t>The entity-header field "Expires" gives the date/time after which the response is 1070 considered stale. See <xref target="expiration.model" /> for further discussion of the 1071 freshness model.</t> 1072 <t>The presence of an Expires field does not imply that the original resource will change or 1073 cease to exist at, before, or after that time.</t> 1074 <t>The field-value is an absolute date and time as defined by HTTP-date in &full-date;; 1075 it &MUST; be sent in rfc1123-date format.</t> 1200 </artwork></figure> 1201 <t> 1202 A cache seeing this header field will act correctly even if the cache does not 1203 understand the community cache-extension, since it will also see and understand the 1204 private directive and thus default to the safe behavior. 1205 </t> 1206 <t> 1207 Unrecognized cache directives &MUST; be ignored; it is assumed that any cache 1208 directive likely to be unrecognized by an HTTP/1.1 cache will be combined with standard 1209 directives (or the response's default cacheability) such that the cache behavior will 1210 remain minimally correct even if the cache does not understand the extension(s). 1211 </t> 1212 </section> 1213 1214 </section> 1215 1216 <section anchor="header.expires" title="Expires"> 1217 <iref item="Expires header" primary="true" x:for-anchor="" /> 1218 <iref item="Headers" primary="true" subitem="Expires" x:for-anchor="" /> 1219 <x:anchor-alias value="Expires"/> 1220 <x:anchor-alias value="Expires-v"/> 1221 <t> 1222 The entity-header field "Expires" gives the date/time after which the response is 1223 considered stale. See <xref target="expiration.model" /> for further discussion of the 1224 freshness model. 1225 </t> 1226 <t> 1227 The presence of an Expires field does not imply that the original resource will change or 1228 cease to exist at, before, or after that time. 1229 </t> 1230 <t> 1231 The field-value is an absolute date and time as defined by HTTP-date in &full-date;; 1232 it &MUST; be sent in rfc1123-date format. 1233 </t> 1076 1234 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Expires"/><iref primary="true" item="Grammar" subitem="Expires-v"/> 1077 1235 <x:ref>Expires</x:ref> = "Expires" ":" <x:ref>OWS</x:ref> <x:ref>Expires-v</x:ref> 1078 1236 <x:ref>Expires-v</x:ref> = <x:ref>HTTP-date</x:ref> 1079 1237 </artwork></figure> 1080 <t>For example</t>1081 <figure>1082 1238 <figure> 1239 <preamble>For example</preamble> 1240 <artwork type="example"> 1083 1241 Expires: Thu, 01 Dec 1994 16:00:00 GMT 1084 </artwork> 1085 </figure> 1086 <t> 1087 <list> 1088 <t> 1089 <x:h>Note:</x:h> if a response includes a Cache-Control field with the max-age 1090 directive (see <xref target="cache-response-directive" />), that directive overrides 1091 the Expires field. Likewise, the s-maxage directive overrides Expires in shared caches.</t> 1092 </list> 1093 </t> 1094 <t>HTTP/1.1 servers &SHOULD-NOT; send Expires dates more than one year in the future.</t> 1095 <t>HTTP/1.1 clients and caches &MUST; treat other invalid date formats, especially 1096 including the value "0", as in the past (i.e., "already expired").</t> 1097 </section> 1098 1099 <section anchor="header.pragma" title="Pragma"> 1100 <iref item="Pragma header" primary="true" x:for-anchor="" /> 1101 <iref item="Headers" primary="true" subitem="Pragma" x:for-anchor="" /> 1102 <x:anchor-alias value="extension-pragma"/> 1103 <x:anchor-alias value="Pragma"/> 1104 <x:anchor-alias value="Pragma-v"/> 1105 <x:anchor-alias value="pragma-directive"/> 1106 <t>The general-header field "Pragma" is used to include implementation-specific directives 1107 that might apply to any recipient along the request/response chain. All pragma directives 1108 specify optional behavior from the viewpoint of the protocol; however, some systems 1109 &MAY; require that behavior be consistent with the directives.</t> 1242 </artwork></figure> 1243 <x:note> 1244 <t> 1245 <x:h>Note:</x:h> if a response includes a Cache-Control field with the max-age 1246 directive (see <xref target="cache-response-directive" />), that directive overrides 1247 the Expires field. Likewise, the s-maxage directive overrides Expires in shared caches.</t> 1248 </x:note> 1249 <t> 1250 HTTP/1.1 servers &SHOULD-NOT; send Expires dates more than one year in the future. 1251 </t> 1252 <t> 1253 HTTP/1.1 clients and caches &MUST; treat other invalid date formats, especially 1254 including the value "0", as in the past (i.e., "already expired"). 1255 </t> 1256 </section> 1257 1258 <section anchor="header.pragma" title="Pragma"> 1259 <iref item="Pragma header" primary="true" x:for-anchor="" /> 1260 <iref item="Headers" primary="true" subitem="Pragma" x:for-anchor="" /> 1261 <x:anchor-alias value="extension-pragma"/> 1262 <x:anchor-alias value="Pragma"/> 1263 <x:anchor-alias value="Pragma-v"/> 1264 <x:anchor-alias value="pragma-directive"/> 1265 <t 1266 >The general-header field "Pragma" is used to include implementation-specific directives 1267 that might apply to any recipient along the request/response chain. All pragma directives 1268 specify optional behavior from the viewpoint of the protocol; however, some systems 1269 &MAY; require that behavior be consistent with the directives. 1270 </t> 1110 1271 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Pragma"/><iref primary="true" item="Grammar" subitem="Pragma-v"/><iref primary="true" item="Grammar" subitem="pragma-directive"/><iref primary="true" item="Grammar" subitem="extension-pragma"/> 1111 1272 <x:ref>Pragma</x:ref> = "Pragma" ":" <x:ref>OWS</x:ref> <x:ref>Pragma-v</x:ref> … … 1114 1275 <x:ref>extension-pragma</x:ref> = <x:ref>token</x:ref> [ "=" ( <x:ref>token</x:ref> / <x:ref>quoted-string</x:ref> ) ] 1115 1276 </artwork></figure> 1116 <t>When the no-cache directive is present in a request message, an application &SHOULD; 1117 forward the request toward the origin server even if it has a cached copy of what is being 1118 requested. This pragma directive has the same semantics as the no-cache response directive 1119 (see <xref target="cache-response-directive" />) and is defined here for backward 1120 compatibility with HTTP/1.0. Clients &SHOULD; include both header fields when a 1121 no-cache request is sent to a server not known to be HTTP/1.1 compliant. HTTP/1.1 caches 1122 &SHOULD; treat "Pragma: no-cache" as if the client had sent "Cache-Control: no-cache".</t> 1123 <t> 1124 <list> 1125 <t> 1126 <x:h>Note:</x:h> because the meaning of "Pragma: no-cache" as a response-header field 1127 is not actually specified, it does not provide a reliable replacement for 1128 "Cache-Control: no-cache" in a response.</t> 1129 </list> 1130 </t> 1131 <t>This mechanism is deprecated; no new Pragma directives will be defined in HTTP.</t> 1132 </section> 1133 1134 <section anchor="header.vary" title="Vary"> 1135 <iref item="Vary header" primary="true" x:for-anchor="" /> 1136 <iref item="Headers" primary="true" subitem="Vary" x:for-anchor="" /> 1137 <x:anchor-alias value="Vary"/> 1138 <x:anchor-alias value="Vary-v"/> 1139 <t>The "Vary" response-header field's value indicates the set of request-header fields that 1140 determines, while the response is fresh, whether a cache is permitted to use the 1141 response to reply to a subsequent request without validation; see <xref 1142 target="caching.negotiated.responses" />.</t> 1143 <t>In uncacheable or stale responses, the Vary field value advises the user agent about 1144 the criteria that were used to select the representation.</t> 1277 <t> 1278 When the no-cache directive is present in a request message, an application &SHOULD; 1279 forward the request toward the origin server even if it has a cached copy of what is being 1280 requested. This pragma directive has the same semantics as the no-cache response directive 1281 (see <xref target="cache-response-directive" />) and is defined here for backward 1282 compatibility with HTTP/1.0. Clients &SHOULD; include both header fields when a 1283 no-cache request is sent to a server not known to be HTTP/1.1 compliant. HTTP/1.1 caches 1284 &SHOULD; treat "Pragma: no-cache" as if the client had sent "Cache-Control: no-cache". 1285 </t> 1286 <x:note> 1287 <t> 1288 <x:h>Note:</x:h> because the meaning of "Pragma: no-cache" as a response-header field 1289 is not actually specified, it does not provide a reliable replacement for 1290 "Cache-Control: no-cache" in a response.</t> 1291 </x:note> 1292 <t> 1293 This mechanism is deprecated; no new Pragma directives will be defined in HTTP. 1294 </t> 1295 </section> 1296 1297 <section anchor="header.vary" title="Vary"> 1298 <iref item="Vary header" primary="true" x:for-anchor="" /> 1299 <iref item="Headers" primary="true" subitem="Vary" x:for-anchor="" /> 1300 <x:anchor-alias value="Vary"/> 1301 <x:anchor-alias value="Vary-v"/> 1302 <t> 1303 The "Vary" response-header field's value indicates the set of request-header fields that 1304 determines, while the response is fresh, whether a cache is permitted to use the 1305 response to reply to a subsequent request without validation; see <xref 1306 target="caching.negotiated.responses" />. 1307 </t> 1308 <t> 1309 In uncacheable or stale responses, the Vary field value advises the user agent about 1310 the criteria that were used to select the representation. 1311 </t> 1145 1312 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Vary"/><iref primary="true" item="Grammar" subitem="Vary-v"/> 1146 1313 <x:ref>Vary</x:ref> = "Vary" ":" <x:ref>OWS</x:ref> <x:ref>Vary-v</x:ref> 1147 1314 <x:ref>Vary-v</x:ref> = "*" / 1#<x:ref>field-name</x:ref> 1148 1315 </artwork></figure> 1149 <t>The set of header fields named by the Vary field value is known as the selecting 1150 request-headers.</t> 1151 <t>Servers &SHOULD; include a Vary header field with any cacheable response that is 1152 subject to server-driven negotiation. Doing so allows a cache to properly interpret future 1153 requests on that resource and informs the user agent about the presence of negotiation on 1154 that resource. A server &MAY; include a Vary header field with a non-cacheable 1155 response that is subject to server-driven negotiation, since this might provide the user 1156 agent with useful information about the dimensions over which the response varies at the 1157 time of the response.</t> 1158 <t>A Vary field value of "*" signals that unspecified parameters not limited to the 1159 request-headers (e.g., the network address of the client), play a role in the selection of 1160 the response representation; therefore, a cache cannot determine whether this response is 1161 appropriate. The "*" value &MUST-NOT; be generated by a proxy server; 1162 it may only be generated by an origin server.</t> 1163 <t>The field-names given are not limited to the set of standard request-header fields 1164 defined by this specification. Field names are case-insensitive.</t> 1165 </section> 1166 1167 <section anchor="header.warning" title="Warning"> 1168 <iref item="Warning header" primary="true" x:for-anchor="" /> 1169 <iref item="Headers" primary="true" subitem="Warning" x:for-anchor="" /> 1170 <x:anchor-alias value="Warning"/> 1171 <x:anchor-alias value="Warning-v"/> 1172 <x:anchor-alias value="warning-value"/> 1173 <x:anchor-alias value="warn-agent"/> 1174 <x:anchor-alias value="warn-code"/> 1175 <x:anchor-alias value="warn-date"/> 1176 <x:anchor-alias value="warn-text"/> 1177 <t>The general-header field "Warning" is used to carry additional information about the status 1178 or transformation of a message that might not be reflected in the message. This 1179 information is typically used to warn about possible incorrectness introduced by caching 1180 operations or transformations applied to the entity body of the message.</t> 1181 <t>Warnings can be used for other purposes, both cache-related and otherwise. The use of a 1182 warning, rather than an error status code, distinguish these responses from true failures.</t> 1183 1184 <t>Warning headers can in general be applied to any message, however some warn-codes are 1185 specific to caches and can only be applied to response messages.</t> 1186 1316 <t> 1317 The set of header fields named by the Vary field value is known as the selecting 1318 request-headers. 1319 </t> 1320 <t> 1321 Servers &SHOULD; include a Vary header field with any cacheable response that is 1322 subject to server-driven negotiation. Doing so allows a cache to properly interpret future 1323 requests on that resource and informs the user agent about the presence of negotiation on 1324 that resource. A server &MAY; include a Vary header field with a non-cacheable 1325 response that is subject to server-driven negotiation, since this might provide the user 1326 agent with useful information about the dimensions over which the response varies at the 1327 time of the response. 1328 </t> 1329 <t> 1330 A Vary field value of "*" signals that unspecified parameters not limited to the 1331 request-headers (e.g., the network address of the client), play a role in the selection of 1332 the response representation; therefore, a cache cannot determine whether this response is 1333 appropriate. The "*" value &MUST-NOT; be generated by a proxy server; 1334 it may only be generated by an origin server. 1335 </t> 1336 <t> 1337 The field-names given are not limited to the set of standard request-header fields 1338 defined by this specification. Field names are case-insensitive. 1339 </t> 1340 </section> 1341 1342 <section anchor="header.warning" title="Warning"> 1343 <iref item="Warning header" primary="true" x:for-anchor="" /> 1344 <iref item="Headers" primary="true" subitem="Warning" x:for-anchor="" /> 1345 <x:anchor-alias value="Warning"/> 1346 <x:anchor-alias value="Warning-v"/> 1347 <x:anchor-alias value="warning-value"/> 1348 <x:anchor-alias value="warn-agent"/> 1349 <x:anchor-alias value="warn-code"/> 1350 <x:anchor-alias value="warn-date"/> 1351 <x:anchor-alias value="warn-text"/> 1352 <t> 1353 The general-header field "Warning" is used to carry additional information about the status 1354 or transformation of a message that might not be reflected in the message. This 1355 information is typically used to warn about possible incorrectness introduced by caching 1356 operations or transformations applied to the entity body of the message. 1357 </t> 1358 <t> 1359 Warnings can be used for other purposes, both cache-related and otherwise. The use of a 1360 warning, rather than an error status code, distinguish these responses from true failures. 1361 </t> 1362 <t> 1363 Warning headers can in general be applied to any message, however some warn-codes are 1364 specific to caches and can only be applied to response messages. 1365 </t> 1187 1366 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Warning"/><iref primary="true" item="Grammar" subitem="Warning-v"/><iref primary="true" item="Grammar" subitem="warning-value"/><iref primary="true" item="Grammar" subitem="warn-code"/><iref primary="true" item="Grammar" subitem="warn-agent"/><iref primary="true" item="Grammar" subitem="warn-text"/><iref primary="true" item="Grammar" subitem="warn-date"/> 1188 1367 <x:ref>Warning</x:ref> = "Warning" ":" <x:ref>OWS</x:ref> <x:ref>Warning-v</x:ref> … … 1199 1378 <x:ref>warn-date</x:ref> = <x:ref>DQUOTE</x:ref> <x:ref>HTTP-date</x:ref> <x:ref>DQUOTE</x:ref> 1200 1379 </artwork></figure> 1201 1202 <t>Multiple warnings can be attached to a response (either by the origin server or by 1203 a cache), including multiple warnings with the same code number. For example, a server 1204 might provide the same warning with texts in both English and Basque.</t> 1205 <t>When this occurs, the user agent &SHOULD; inform the user of as many of them as 1206 possible, in the order that they appear in the response. If it is not possible to inform 1207 the user of all of the warnings, the user agent &SHOULD; follow these heuristics: 1208 <list style="symbols"> 1209 <t>Warnings that appear early in the response take priority over those appearing later 1210 in the response.</t> 1211 1212 <t>Warnings in the user's preferred character set take priority over warnings in other 1213 character sets but with identical warn-codes and warn-agents.</t> 1214 </list> 1215 </t> 1216 <t>Systems that generate multiple Warning headers &SHOULD; order them with this user 1217 agent behavior in mind. New Warning headers &SHOULD; be added after any existing 1218 Warning headers.</t> 1219 <t>Warnings are assigned three digit warn-codes. The first digit indicates whether the 1220 Warning is required to be deleted from a stored response after validation: <list 1221 style="symbols"> 1222 <t>1xx Warnings that describe the freshness or validation status of the response, and so 1223 &MUST; be deleted by caches after validation. They &MUST-NOT; be generated by a cache 1224 except when validating a cached entry, and &MUST-NOT; be generated by clients.</t> 1225 <t>2xx Warnings that describe some aspect of the entity body or entity headers that is 1226 not rectified by a validation (for example, a lossy compression of the entity bodies) 1227 and &MUST-NOT; be deleted by caches after validation, unless a full response is 1228 returned, in which case they &MUST; be.</t> 1229 </list> 1230 </t> 1231 <t>The warn-text &SHOULD; be in a natural language and character set that is most likely 1232 to be intelligible to the human user receiving the response. This decision can be based on 1233 any available knowledge, such as the location of the cache or user, the Accept-Language 1234 field in a request, the Content-Language field in a response, etc. The default language is 1235 English and the default character set is ISO-8859-1 (<xref target="ISO-8859-1" />).</t> 1236 <t>If a character set other than ISO-8859-1 is used, it &MUST; be encoded in the 1237 warn-text using the method described in <xref target="RFC2047" />.</t> 1238 <t>If an implementation sends a message with one or more Warning headers to a receiver whose 1239 version is HTTP/1.0 or lower, then the sender &MUST; include in each warning-value a 1240 warn-date that matches the Date header in the message.</t> 1241 <t>If an implementation receives a message with a warning-value that includes a warn-date, 1242 and that warn-date is different from the Date value in the response, then that 1243 warning-value &MUST; be deleted from the message before storing, forwarding, or using 1244 it. (preventing the consequences of naive caching of Warning header fields.) If all of the 1245 warning-values are deleted for this reason, the Warning header &MUST; be deleted as 1246 well.</t> 1247 <t>The following warn-codes are defined by this specification, each with a recommended 1248 warn-text in English, and a description of its meaning.</t> 1249 <t>110 Response is stale <list> 1250 <t>&SHOULD; be included whenever the returned response is stale.</t> 1251 </list> 1252 </t> 1253 <t>111 Revalidation failed <list> 1254 <t>&SHOULD; be included if a cache returns a stale response because an attempt to 1255 validate the response failed, due to an inability to reach the server.</t> 1256 </list> 1257 </t> 1258 <t>112 Disconnected operation <list> 1259 <t>&SHOULD; be included if the cache is intentionally disconnected from the rest of 1260 the network for a period of time.</t> 1261 </list> 1262 </t> 1263 <t>113 Heuristic expiration <list> 1264 <t>&SHOULD; be included if the cache heuristically chose a freshness lifetime 1265 greater than 24 hours and the response's age is greater than 24 hours.</t> 1266 </list> 1267 </t> 1268 <t>199 Miscellaneous warning <list> 1269 <t>The warning text can include arbitrary information to be presented to a human 1270 user, or logged. A system receiving this warning &MUST-NOT; take any automated 1271 action, besides presenting the warning to the user.</t> 1272 </list> 1273 </t> 1274 <t>214 Transformation applied <list> 1275 <t>&MUST; be added by an intermediate cache or proxy if it applies any 1276 transformation changing the content-coding (as specified in the Content-Encoding 1277 header) or media-type (as specified in the Content-Type header) of the response, or 1278 the entity-body of the response, unless this Warning code already appears in the 1279 response.</t> 1280 </list> 1281 </t> 1282 <t>299 Miscellaneous persistent warning <list> 1283 <t>The warning text can include arbitrary information to be presented to a human 1284 user, or logged. A system receiving this warning &MUST-NOT; take any automated 1285 action.</t> 1286 </list> 1287 </t> 1288 </section> 1289 1290 </section> 1291 1292 1293 <section anchor="history.lists" title="History Lists"> 1294 <t>User agents often have history mechanisms, such as "Back" buttons and history lists, that 1295 can be used to redisplay an entity retrieved earlier in a session.</t> 1296 <t>History mechanisms and caches are different. In particular history mechanisms 1297 &SHOULD-NOT; try to show a correct view of the current state of a resource. Rather, a 1298 history mechanism is meant to show exactly what the user saw at the time when the resource 1299 was retrieved.</t> 1300 <t>By default, an expiration time does not apply to history mechanisms. If the entity is still 1301 in storage, a history mechanism &SHOULD; display it even if the entity has expired, 1302 unless the user has specifically configured the agent to refresh expired history documents.</t> 1303 <t>This is not to be construed to prohibit the history mechanism from telling the user that a 1304 view might be stale. <list> 1305 <t> 1306 <x:h>Note:</x:h> if history list mechanisms unnecessarily prevent users from viewing 1307 stale resources, this will tend to force service authors to avoid using HTTP expiration 1308 controls and cache controls when they would otherwise like to. Service authors may 1309 consider it important that users not be presented with error messages or warning 1310 messages when they use navigation controls (such as BACK) to view previously fetched 1311 resources. Even though sometimes such resources ought not be cached, or ought to expire 1312 quickly, user interface considerations may force service authors to resort to other 1313 means of preventing caching (e.g. "once-only" URLs) in order not to suffer the effects 1314 of improperly functioning history mechanisms.</t> 1315 </list> 1316 </t> 1317 </section> 1318 1319 1320 <section anchor="IANA.considerations" title="IANA Considerations"> 1321 <section anchor="message.header.registration" title="Message Header Registration"> 1322 <t>The Message Header Registry located at <eref 1323 target="http://www.iana.org/assignments/message-headers/message-header-index.html" /> 1324 should be updated with the permanent registrations below (see <xref target="RFC3864" />):</t> 1325 <!--AUTOGENERATED FROM extract-header-defs.xslt, do not edit manually--> 1326 <texttable align="left" anchor="iana.header.registration.table" suppress-title="true"> 1327 <ttcol>Header Field Name</ttcol> 1328 <ttcol>Protocol</ttcol> 1329 <ttcol>Status</ttcol> 1330 <ttcol>Reference</ttcol> 1331 1332 <c>Age</c> 1333 <c>http</c> 1334 <c>standard</c> 1335 <c> 1336 <xref target="header.age" /> 1337 </c> 1338 <c>Cache-Control</c> 1339 <c>http</c> 1340 <c>standard</c> 1341 <c> 1342 <xref target="header.cache-control" /> 1343 </c> 1344 <c>Expires</c> 1345 <c>http</c> 1346 <c>standard</c> 1347 <c> 1348 <xref target="header.expires" /> 1349 </c> 1350 <c>Pragma</c> 1351 <c>http</c> 1352 <c>standard</c> 1353 <c> 1354 <xref target="header.pragma" /> 1355 </c> 1356 <c>Vary</c> 1357 <c>http</c> 1358 <c>standard</c> 1359 <c> 1360 <xref target="header.vary" /> 1361 </c> 1362 <c>Warning</c> 1363 <c>http</c> 1364 <c>standard</c> 1365 <c> 1366 <xref target="header.warning" /> 1367 </c> 1368 </texttable> 1369 <!--(END)--> 1370 <t>The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</t> 1371 </section> 1372 </section> 1373 1374 <section anchor="security.considerations" title="Security Considerations"> 1375 <t>Caches expose additional potential vulnerabilities, since the contents of the cache 1376 represent an attractive target for malicious exploitation. Because cache contents persist 1377 after an HTTP request is complete, an attack on the cache can reveal information long after 1378 a user believes that the information has been removed from the network. Therefore, cache 1379 contents should be protected as sensitive information.</t> 1380 </section> 1381 1382 <section anchor="ack" title="Acknowledgments"> 1383 <t>Much of the content and presentation of the caching design is due to suggestions and 1384 comments from individuals including: Shel Kaphan, Paul Leach, Koen Holtman, David Morris, 1385 and Larry Masinter.</t> 1386 </section> 1387 </middle> 1388 1389 <back> 1390 <references title="Normative References"> 1391 1392 <reference anchor="ISO-8859-1"> 1393 <front> 1394 <title> Information technology -- 8-bit single-byte coded graphic character sets -- Part 1395 1: Latin alphabet No. 1 </title> 1396 <author> 1397 <organization>International Organization for Standardization</organization> 1398 </author> 1399 <date year="1998" /> 1400 </front> 1401 <seriesInfo name="ISO/IEC" value="8859-1:1998" /> 1402 </reference> 1403 1404 <reference anchor="Part1"> 1405 <front> 1406 <title abbrev="HTTP/1.1">HTTP/1.1, part 1: URIs, Connections, and Message Parsing</title> 1407 <author fullname="Roy T. Fielding" initials="R." role="editor" surname="Fielding"> 1408 <organization abbrev="Day Software">Day Software</organization> 1409 <address><email>fielding@gbiv.com</email></address> 1410 </author> 1411 <author fullname="Jim Gettys" initials="J." surname="Gettys"> 1412 <organization>One Laptop per Child</organization> 1413 <address><email>jg@laptop.org</email></address> 1414 </author> 1415 <author fullname="Jeffrey C. Mogul" initials="J." surname="Mogul"> 1416 <organization abbrev="HP">Hewlett-Packard Company</organization> 1417 <address><email>JeffMogul@acm.org</email></address> 1418 </author> 1419 <author fullname="Henrik Frystyk Nielsen" initials="H." surname="Frystyk"> 1420 <organization abbrev="Microsoft">Microsoft Corporation</organization> 1421 <address><email>henrikn@microsoft.com</email></address> 1422 </author> 1423 <author fullname="Larry Masinter" initials="L." surname="Masinter"> 1424 <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization> 1425 <address><email>LMM@acm.org</email></address> 1426 </author> 1427 <author fullname="Paul J. Leach" initials="P." surname="Leach"> 1428 <organization abbrev="Microsoft">Microsoft Corporation</organization> 1429 <address><email>paulle@microsoft.com</email></address> 1430 </author> 1431 <author fullname="Tim Berners-Lee" initials="T." surname="Berners-Lee"> 1432 <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> 1433 <address><email>timbl@w3.org</email></address> 1434 </author> 1435 <author fullname="Yves Lafon" initials="Y." role="editor" surname="Lafon"> 1436 <organization abbrev="W3C">World Wide Web Consortium</organization> 1437 <address><email>ylafon@w3.org</email></address> 1438 </author> 1439 <author fullname="Julian F. Reschke" initials="J. F." role="editor" surname="Reschke"> 1440 <organization abbrev="greenbytes">greenbytes GmbH</organization> 1441 <address><email>julian.reschke@greenbytes.de</email></address> 1442 </author> 1443 <date month="&ID-MONTH;" year="&ID-YEAR;" /> 1444 </front> 1445 <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p1-messaging-&ID-VERSION;" /> 1446 <x:source basename="p1-messaging" href="p1-messaging.xml" /> 1447 </reference> 1448 1449 <reference anchor="Part2"> 1450 <front> 1451 <title abbrev="HTTP/1.1">HTTP/1.1, part 2: Message Semantics</title> 1452 <author fullname="Roy T. Fielding" initials="R." role="editor" surname="Fielding"> 1453 <organization abbrev="Day Software">Day Software</organization> 1454 <address><email>fielding@gbiv.com</email></address> 1455 </author> 1456 <author fullname="Jim Gettys" initials="J." surname="Gettys"> 1457 <organization>One Laptop per Child</organization> 1458 <address><email>jg@laptop.org</email></address> 1459 </author> 1460 <author fullname="Jeffrey C. Mogul" initials="J." surname="Mogul"> 1461 <organization abbrev="HP">Hewlett-Packard Company</organization> 1462 <address><email>JeffMogul@acm.org</email></address> 1463 </author> 1464 <author fullname="Henrik Frystyk Nielsen" initials="H." surname="Frystyk"> 1465 <organization abbrev="Microsoft">Microsoft Corporation</organization> 1466 <address><email>henrikn@microsoft.com</email></address> 1467 </author> 1468 <author fullname="Larry Masinter" initials="L." surname="Masinter"> 1469 <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization> 1470 <address><email>LMM@acm.org</email></address> 1471 </author> 1472 <author fullname="Paul J. Leach" initials="P." surname="Leach"> 1473 <organization abbrev="Microsoft">Microsoft Corporation</organization> 1474 <address><email>paulle@microsoft.com</email></address> 1475 </author> 1476 <author fullname="Tim Berners-Lee" initials="T." surname="Berners-Lee"> 1477 <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> 1478 <address><email>timbl@w3.org</email></address> 1479 </author> 1480 <author fullname="Yves Lafon" initials="Y." role="editor" surname="Lafon"> 1481 <organization abbrev="W3C">World Wide Web Consortium</organization> 1482 <address><email>ylafon@w3.org</email></address> 1483 </author> 1484 <author fullname="Julian F. Reschke" initials="J. F." role="editor" surname="Reschke"> 1485 <organization abbrev="greenbytes">greenbytes GmbH</organization> 1486 <address><email>julian.reschke@greenbytes.de</email></address> 1487 </author> 1488 <date month="&ID-MONTH;" year="&ID-YEAR;" /> 1489 </front> 1490 <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p2-semantics-&ID-VERSION;" /> 1491 <x:source basename="p2-semantics" href="p2-semantics.xml" /> 1492 </reference> 1493 1494 <reference anchor="Part3"> 1495 <front> 1496 <title abbrev="HTTP/1.1">HTTP/1.1, part 3: Message Payload and Content Negotiation</title> 1497 <author fullname="Roy T. Fielding" initials="R." role="editor" surname="Fielding"> 1498 <organization abbrev="Day Software">Day Software</organization> 1499 <address><email>fielding@gbiv.com</email></address> 1500 </author> 1501 <author fullname="Jim Gettys" initials="J." surname="Gettys"> 1502 <organization>One Laptop per Child</organization> 1503 <address><email>jg@laptop.org</email></address> 1504 </author> 1505 <author fullname="Jeffrey C. Mogul" initials="J." surname="Mogul"> 1506 <organization abbrev="HP">Hewlett-Packard Company</organization> 1507 <address><email>JeffMogul@acm.org</email></address> 1508 </author> 1509 <author fullname="Henrik Frystyk Nielsen" initials="H." surname="Frystyk"> 1510 <organization abbrev="Microsoft">Microsoft Corporation</organization> 1511 <address><email>henrikn@microsoft.com</email></address> 1512 </author> 1513 <author fullname="Larry Masinter" initials="L." surname="Masinter"> 1514 <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization> 1515 <address><email>LMM@acm.org</email></address> 1516 </author> 1517 <author fullname="Paul J. Leach" initials="P." surname="Leach"> 1518 <organization abbrev="Microsoft">Microsoft Corporation</organization> 1519 <address><email>paulle@microsoft.com</email></address> 1520 </author> 1521 <author fullname="Tim Berners-Lee" initials="T." surname="Berners-Lee"> 1522 <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> 1523 <address><email>timbl@w3.org</email></address> 1524 </author> 1525 <author fullname="Yves Lafon" initials="Y." role="editor" surname="Lafon"> 1526 <organization abbrev="W3C">World Wide Web Consortium</organization> 1527 <address><email>ylafon@w3.org</email></address> 1528 </author> 1529 <author fullname="Julian F. Reschke" initials="J. F." role="editor" surname="Reschke"> 1530 <organization abbrev="greenbytes">greenbytes GmbH</organization> 1531 <address><email>julian.reschke@greenbytes.de</email></address> 1532 </author> 1533 <date month="&ID-MONTH;" year="&ID-YEAR;" /> 1534 </front> 1535 <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p3-payload-&ID-VERSION;" /> 1536 <x:source basename="p3-payload" href="p3-payload.xml" /> 1537 </reference> 1538 1539 <reference anchor="Part4"> 1540 <front> 1541 <title abbrev="HTTP/1.1">HTTP/1.1, part 4: Conditional Requests</title> 1542 <author fullname="Roy T. Fielding" initials="R." role="editor" surname="Fielding"> 1543 <organization abbrev="Day Software">Day Software</organization> 1544 <address><email>fielding@gbiv.com</email></address> 1545 </author> 1546 <author fullname="Jim Gettys" initials="J." surname="Gettys"> 1547 <organization>One Laptop per Child</organization> 1548 <address><email>jg@laptop.org</email></address> 1549 </author> 1550 <author fullname="Jeffrey C. Mogul" initials="J." surname="Mogul"> 1551 <organization abbrev="HP">Hewlett-Packard Company</organization> 1552 <address><email>JeffMogul@acm.org</email></address> 1553 </author> 1554 <author fullname="Henrik Frystyk Nielsen" initials="H." surname="Frystyk"> 1555 <organization abbrev="Microsoft">Microsoft Corporation</organization> 1556 <address><email>henrikn@microsoft.com</email></address> 1557 </author> 1558 <author fullname="Larry Masinter" initials="L." surname="Masinter"> 1559 <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization> 1560 <address><email>LMM@acm.org</email></address> 1561 </author> 1562 <author fullname="Paul J. Leach" initials="P." surname="Leach"> 1563 <organization abbrev="Microsoft">Microsoft Corporation</organization> 1564 <address><email>paulle@microsoft.com</email></address> 1565 </author> 1566 <author fullname="Tim Berners-Lee" initials="T." surname="Berners-Lee"> 1567 <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> 1568 <address><email>timbl@w3.org</email></address> 1569 </author> 1570 <author fullname="Yves Lafon" initials="Y." role="editor" surname="Lafon"> 1571 <organization abbrev="W3C">World Wide Web Consortium</organization> 1572 <address><email>ylafon@w3.org</email></address> 1573 </author> 1574 <author fullname="Julian F. Reschke" initials="J. F." role="editor" surname="Reschke"> 1575 <organization abbrev="greenbytes">greenbytes GmbH</organization> 1576 <address><email>julian.reschke@greenbytes.de</email></address> 1577 </author> 1578 <date month="&ID-MONTH;" year="&ID-YEAR;" /> 1579 </front> 1580 <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p4-conditional-&ID-VERSION;" /> 1581 <x:source basename="p4-conditional" href="p4-conditional.xml" /> 1582 </reference> 1583 1584 <reference anchor="Part5"> 1585 <front> 1586 <title abbrev="HTTP/1.1">HTTP/1.1, part 5: Range Requests and Partial Responses</title> 1587 <author fullname="Roy T. Fielding" initials="R." role="editor" surname="Fielding"> 1588 <organization abbrev="Day Software">Day Software</organization> 1589 <address><email>fielding@gbiv.com</email></address> 1590 </author> 1591 <author fullname="Jim Gettys" initials="J." surname="Gettys"> 1592 <organization>One Laptop per Child</organization> 1593 <address><email>jg@laptop.org</email></address> 1594 </author> 1595 <author fullname="Jeffrey C. Mogul" initials="J." surname="Mogul"> 1596 <organization abbrev="HP">Hewlett-Packard Company</organization> 1597 <address><email>JeffMogul@acm.org</email></address> 1598 </author> 1599 <author fullname="Henrik Frystyk Nielsen" initials="H." surname="Frystyk"> 1600 <organization abbrev="Microsoft">Microsoft Corporation</organization> 1601 <address><email>henrikn@microsoft.com</email></address> 1602 </author> 1603 <author fullname="Larry Masinter" initials="L." surname="Masinter"> 1604 <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization> 1605 <address><email>LMM@acm.org</email></address> 1606 </author> 1607 <author fullname="Paul J. Leach" initials="P." surname="Leach"> 1608 <organization abbrev="Microsoft">Microsoft Corporation</organization> 1609 <address><email>paulle@microsoft.com</email></address> 1610 </author> 1611 <author fullname="Tim Berners-Lee" initials="T." surname="Berners-Lee"> 1612 <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> 1613 <address><email>timbl@w3.org</email></address> 1614 </author> 1615 <author fullname="Yves Lafon" initials="Y." role="editor" surname="Lafon"> 1616 <organization abbrev="W3C">World Wide Web Consortium</organization> 1617 <address><email>ylafon@w3.org</email></address> 1618 </author> 1619 <author fullname="Julian F. Reschke" initials="J. F." role="editor" surname="Reschke"> 1620 <organization abbrev="greenbytes">greenbytes GmbH</organization> 1621 <address><email>julian.reschke@greenbytes.de</email></address> 1622 </author> 1623 <date month="&ID-MONTH;" year="&ID-YEAR;" /> 1624 </front> 1625 <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p5-range-&ID-VERSION;" /> 1626 <x:source basename="p5-range" href="p5-range.xml" /> 1627 </reference> 1628 1629 <reference anchor="Part7"> 1630 <front> 1631 <title abbrev="HTTP/1.1">HTTP/1.1, part 7: Authentication</title> 1632 <author fullname="Roy T. Fielding" initials="R." role="editor" surname="Fielding"> 1633 <organization abbrev="Day Software">Day Software</organization> 1634 <address><email>fielding@gbiv.com</email></address> 1635 </author> 1636 <author fullname="Jim Gettys" initials="J." surname="Gettys"> 1637 <organization>One Laptop per Child</organization> 1638 <address><email>jg@laptop.org</email></address> 1639 </author> 1640 <author fullname="Jeffrey C. Mogul" initials="J." surname="Mogul"> 1641 <organization abbrev="HP">Hewlett-Packard Company</organization> 1642 <address><email>JeffMogul@acm.org</email></address> 1643 </author> 1644 <author fullname="Henrik Frystyk Nielsen" initials="H." surname="Frystyk"> 1645 <organization abbrev="Microsoft">Microsoft Corporation</organization> 1646 <address><email>henrikn@microsoft.com</email></address> 1647 </author> 1648 <author fullname="Larry Masinter" initials="L." surname="Masinter"> 1649 <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization> 1650 <address><email>LMM@acm.org</email></address> 1651 </author> 1652 <author fullname="Paul J. Leach" initials="P." surname="Leach"> 1653 <organization abbrev="Microsoft">Microsoft Corporation</organization> 1654 <address><email>paulle@microsoft.com</email></address> 1655 </author> 1656 <author fullname="Tim Berners-Lee" initials="T." surname="Berners-Lee"> 1657 <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> 1658 <address><email>timbl@w3.org</email></address> 1659 </author> 1660 <author fullname="Yves Lafon" initials="Y." role="editor" surname="Lafon"> 1661 <organization abbrev="W3C">World Wide Web Consortium</organization> 1662 <address><email>ylafon@w3.org</email></address> 1663 </author> 1664 <author fullname="Julian F. Reschke" initials="J. F." role="editor" surname="Reschke"> 1665 <organization abbrev="greenbytes">greenbytes GmbH</organization> 1666 <address><email>julian.reschke@greenbytes.de</email></address> 1667 </author> 1668 <date month="&ID-MONTH;" year="&ID-YEAR;" /> 1669 </front> 1670 <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p7-auth-&ID-VERSION;" /> 1671 <x:source basename="p7-auth" href="p7-auth.xml" /> 1672 </reference> 1673 1674 <reference anchor="RFC2047"> 1675 <front> 1676 <title abbrev="Message Header Extensions">MIME (Multipurpose Internet Mail Extensions) 1677 Part Three: Message Header Extensions for Non-ASCII Text</title> 1678 <author fullname="Keith Moore" initials="K." surname="Moore"> 1679 <organization>University of Tennessee</organization> 1680 <address><email>moore@cs.utk.edu</email></address> 1681 </author> 1682 <date month="November" year="1996" /> 1683 </front> 1684 <seriesInfo name="RFC" value="2047" /> 1685 </reference> 1686 1687 <reference anchor="RFC2119"> 1688 <front> 1689 <title>Key words for use in RFCs to Indicate Requirement Levels</title> 1690 <author fullname="Scott Bradner" initials="S." surname="Bradner"> 1691 <organization>Harvard University</organization> 1692 <address><email>sob@harvard.edu</email></address> 1693 </author> 1694 <date month="March" year="1997" /> 1695 </front> 1696 <seriesInfo name="BCP" value="14" /> 1697 <seriesInfo name="RFC" value="2119" /> 1698 </reference> 1699 1700 <reference anchor="RFC5234"> 1701 <front> 1702 <title abbrev="ABNF for Syntax Specifications">Augmented BNF for Syntax Specifications: ABNF</title> 1703 <author initials="D." surname="Crocker" fullname="Dave Crocker" role="editor"> 1704 <organization>Brandenburg InternetWorking</organization> 1705 <address> 1706 <postal> 1707 <street>675 Spruce Dr.</street> 1708 <city>Sunnyvale</city> 1709 <region>CA</region> 1710 <code>94086</code> 1711 <country>US</country></postal> 1712 <phone>+1.408.246.8253</phone> 1713 <email>dcrocker@bbiw.net</email></address> 1714 </author> 1715 <author initials="P." surname="Overell" fullname="Paul Overell"> 1716 <organization>THUS plc.</organization> 1717 <address> 1718 <postal> 1719 <street>1/2 Berkeley Square</street> 1720 <street>99 Berkely Street</street> 1721 <city>Glasgow</city> 1722 <code>G3 7HR</code> 1723 <country>UK</country></postal> 1724 <email>paul.overell@thus.net</email></address> 1725 </author> 1726 <date month="January" year="2008"/> 1727 </front> 1728 <seriesInfo name="STD" value="68"/> 1729 <seriesInfo name="RFC" value="5234"/> 1730 </reference> 1731 1732 </references> 1733 1734 <references title="Informative References"> 1735 1736 <reference anchor="RFC1305"> 1737 <front> 1738 <title>Network Time Protocol (Version 3) Specification, Implementation</title> 1739 <author fullname="David L. Mills" initials="D." surname="Mills"> 1740 <organization>University of Delaware, Electrical Engineering Department</organization> 1741 <address><email>mills@udel.edu</email></address> 1742 </author> 1743 <date month="March" year="1992" /> 1744 </front> 1745 <seriesInfo name="RFC" value="1305" /> 1746 </reference> 1747 1748 <reference anchor="RFC2616"> 1749 <front> 1750 <title>Hypertext Transfer Protocol -- HTTP/1.1</title> 1751 <author fullname="R. Fielding" initials="R." surname="Fielding"> 1752 <organization>University of California, Irvine</organization> 1753 <address><email>fielding@ics.uci.edu</email></address> 1754 </author> 1755 <author fullname="J. Gettys" initials="J." surname="Gettys"> 1756 <organization>W3C</organization> 1757 <address><email>jg@w3.org</email></address> 1758 </author> 1759 <author fullname="J. Mogul" initials="J." surname="Mogul"> 1760 <organization>Compaq Computer Corporation</organization> 1761 <address><email>mogul@wrl.dec.com</email></address> 1762 </author> 1763 <author fullname="H. Frystyk" initials="H." surname="Frystyk"> 1764 <organization>MIT Laboratory for Computer Science</organization> 1765 <address><email>frystyk@w3.org</email></address> 1766 </author> 1767 <author fullname="L. Masinter" initials="L." surname="Masinter"> 1768 <organization>Xerox Corporation</organization> 1769 <address><email>masinter@parc.xerox.com</email></address> 1770 </author> 1771 <author fullname="P. Leach" initials="P." surname="Leach"> 1772 <organization>Microsoft Corporation</organization> 1773 <address><email>paulle@microsoft.com</email></address> 1774 </author> 1775 <author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee"> 1776 <organization>W3C</organization> 1777 <address><email>timbl@w3.org</email></address> 1778 </author> 1779 <date month="June" year="1999" /> 1780 </front> 1781 <seriesInfo name="RFC" value="2616" /> 1782 </reference> 1783 1784 <reference anchor="RFC3864"> 1785 <front> 1786 <title>Registration Procedures for Message Header Fields</title> 1787 <author fullname="G. Klyne" initials="G." surname="Klyne"> 1788 <organization>Nine by Nine</organization> 1789 <address><email>GK-IETF@ninebynine.org</email></address> 1790 </author> 1791 <author fullname="M. Nottingham" initials="M." surname="Nottingham"> 1792 <organization>BEA Systems</organization> 1793 <address><email>mnot@pobox.com</email></address> 1794 </author> 1795 <author fullname="J. Mogul" initials="J." surname="Mogul"> 1796 <organization>HP Labs</organization> 1797 <address><email>JeffMogul@acm.org</email></address> 1798 </author> 1799 <date month="September" year="2004" /> 1800 </front> 1801 <seriesInfo name="BCP" value="90" /> 1802 <seriesInfo name="RFC" value="3864" /> 1803 </reference> 1804 1805 </references> 1806 1807 <section anchor="compatibility" title="Compatibility with Previous Versions"> 1808 1809 <section anchor="changes.from.rfc.2068" title="Changes from RFC 2068"> 1810 <t>A case was missed in the Cache-Control model of HTTP/1.1; s-maxage was introduced to add 1811 this missing case. (Sections <xref format="counter" target="response.cacheability" />, 1812 <xref format="counter" target="header.cache-control" />).</t> 1813 <t>Transfer-coding and message lengths all interact in ways that required fixing exactly 1814 when chunked encoding is used (to allow for transfer encoding that may not be self 1815 delimiting); it was important to straighten out exactly how message lengths are computed. 1816 (see also <xref target="Part1" />, <xref target="Part3" /> and <xref target="Part5" />) 1817 <cref source="jre">This used to refer to the text about non-modifiable headers, and will have to be updated later on.</cref> 1818 </t> 1819 <t>Proxies should be able to add Content-Length when appropriate. 1820 <cref source="jre">This used to refer to the text about non-modifiable headers, and will have to be updated later on.</cref> 1821 </t> 1822 <t>Range request responses would become very verbose if all meta-data were always returned; 1823 by allowing the server to only send needed headers in a 206 response, this problem can be 1824 avoided. (<xref target="combining.headers" />)</t> 1825 <t>The Cache-Control: max-age directive was not properly defined for responses. (<xref target="cache-response-directive"/>)</t> 1826 <t>Warnings could be cached incorrectly, or not updated appropriately. (Section <xref 1827 format="counter" target="expiration.model" />, <xref format="counter" 1828 target="combining.headers" />, <xref format="counter" target="header.cache-control" />, 1829 and <xref format="counter" target="header.warning" />) Warning also needed to be a general 1830 header, as PUT or other methods may have need for it in requests.</t> 1831 </section> 1832 1833 <section anchor="changes.from.rfc.2616" title="Changes from RFC 2616"> 1834 <t>Clarify denial of service attack avoidance requirement. (<xref 1835 target="invalidation.after.updates.or.deletions" />)</t> 1836 </section> 1380 <t> 1381 Multiple warnings can be attached to a response (either by the origin server or by 1382 a cache), including multiple warnings with the same code number. For example, a server 1383 might provide the same warning with texts in both English and Basque. 1384 </t> 1385 <t> 1386 When this occurs, the user agent &SHOULD; inform the user of as many of them as 1387 possible, in the order that they appear in the response. If it is not possible to inform 1388 the user of all of the warnings, the user agent &SHOULD; follow these heuristics: 1389 <list style="symbols"> 1390 <t>Warnings that appear early in the response take priority over those appearing later 1391 in the response.</t> 1392 <t>Warnings in the user's preferred character set take priority over warnings in other 1393 character sets but with identical warn-codes and warn-agents.</t> 1394 </list> 1395 </t> 1396 <t> 1397 Systems that generate multiple Warning headers &SHOULD; order them with this user 1398 agent behavior in mind. New Warning headers &SHOULD; be added after any existing 1399 Warning headers. 1400 </t> 1401 <t> 1402 Warnings are assigned three digit warn-codes. The first digit indicates whether the 1403 Warning is required to be deleted from a stored response after validation: 1404 <list style="symbols"> 1405 <t>1xx Warnings that describe the freshness or validation status of the response, and so 1406 &MUST; be deleted by caches after validation. They &MUST-NOT; be generated by a cache 1407 except when validating a cached entry, and &MUST-NOT; be generated by clients.</t> 1408 <t>2xx Warnings that describe some aspect of the entity body or entity headers that is 1409 not rectified by a validation (for example, a lossy compression of the entity bodies) 1410 and &MUST-NOT; be deleted by caches after validation, unless a full response is 1411 returned, in which case they &MUST; be.</t> 1412 </list> 1413 </t> 1414 <t> 1415 The warn-text &SHOULD; be in a natural language and character set that is most likely 1416 to be intelligible to the human user receiving the response. This decision can be based on 1417 any available knowledge, such as the location of the cache or user, the Accept-Language 1418 field in a request, the Content-Language field in a response, etc. The default language is 1419 English and the default character set is ISO-8859-1 (<xref target="ISO-8859-1" />). 1420 </t> 1421 <t> 1422 If a character set other than ISO-8859-1 is used, it &MUST; be encoded in the 1423 warn-text using the method described in <xref target="RFC2047" />. 1424 </t> 1425 <t> 1426 If an implementation sends a message with one or more Warning headers to a receiver whose 1427 version is HTTP/1.0 or lower, then the sender &MUST; include in each warning-value a 1428 warn-date that matches the Date header in the message. 1429 </t> 1430 <t> 1431 If an implementation receives a message with a warning-value that includes a warn-date, 1432 and that warn-date is different from the Date value in the response, then that 1433 warning-value &MUST; be deleted from the message before storing, forwarding, or using 1434 it. (preventing the consequences of naive caching of Warning header fields.) If all of the 1435 warning-values are deleted for this reason, the Warning header &MUST; be deleted as 1436 well. 1437 </t> 1438 <t> 1439 The following warn-codes are defined by this specification, each with a recommended 1440 warn-text in English, and a description of its meaning. 1441 </t> 1442 <t> 1443 110 Response is stale 1444 <list> 1445 <t>&SHOULD; be included whenever the returned response is stale.</t> 1446 </list> 1447 </t> 1448 <t> 1449 111 Revalidation failed 1450 <list> 1451 <t>&SHOULD; be included if a cache returns a stale response because an attempt to 1452 validate the response failed, due to an inability to reach the server.</t> 1453 </list> 1454 </t> 1455 <t> 1456 112 Disconnected operation 1457 <list> 1458 <t>&SHOULD; be included if the cache is intentionally disconnected from the rest of 1459 the network for a period of time.</t> 1460 </list> 1461 </t> 1462 <t> 1463 113 Heuristic expiration 1464 <list> 1465 <t>&SHOULD; be included if the cache heuristically chose a freshness lifetime 1466 greater than 24 hours and the response's age is greater than 24 hours.</t> 1467 </list> 1468 </t> 1469 <t> 1470 199 Miscellaneous warning 1471 <list> 1472 <t>The warning text can include arbitrary information to be presented to a human 1473 user, or logged. A system receiving this warning &MUST-NOT; take any automated 1474 action, besides presenting the warning to the user.</t> 1475 </list> 1476 </t> 1477 <t> 1478 214 Transformation applied 1479 <list> 1480 <t>&MUST; be added by an intermediate cache or proxy if it applies any 1481 transformation changing the content-coding (as specified in the Content-Encoding 1482 header) or media-type (as specified in the Content-Type header) of the response, or 1483 the entity-body of the response, unless this Warning code already appears in the 1484 response.</t> 1485 </list> 1486 </t> 1487 <t> 1488 299 Miscellaneous persistent warning 1489 <list> 1490 <t>The warning text can include arbitrary information to be presented to a human 1491 user, or logged. A system receiving this warning &MUST-NOT; take any automated 1492 action.</t> 1493 </list> 1494 </t> 1495 </section> 1496 1497 </section> 1498 1499 <section anchor="history.lists" title="History Lists"> 1500 <t> 1501 User agents often have history mechanisms, such as "Back" buttons and history lists, that 1502 can be used to redisplay an entity retrieved earlier in a session. 1503 </t> 1504 <t> 1505 History mechanisms and caches are different. In particular history mechanisms 1506 &SHOULD-NOT; try to show a correct view of the current state of a resource. Rather, a 1507 history mechanism is meant to show exactly what the user saw at the time when the resource 1508 was retrieved. 1509 </t> 1510 <t> 1511 By default, an expiration time does not apply to history mechanisms. If the entity is still 1512 in storage, a history mechanism &SHOULD; display it even if the entity has expired, 1513 unless the user has specifically configured the agent to refresh expired history documents. 1514 </t> 1515 <t> 1516 This is not to be construed to prohibit the history mechanism from telling the user that a 1517 view might be stale. 1518 <list> 1519 <t> 1520 <x:h>Note:</x:h> if history list mechanisms unnecessarily prevent users from viewing 1521 stale resources, this will tend to force service authors to avoid using HTTP expiration 1522 controls and cache controls when they would otherwise like to. Service authors may 1523 consider it important that users not be presented with error messages or warning 1524 messages when they use navigation controls (such as BACK) to view previously fetched 1525 resources. Even though sometimes such resources ought not be cached, or ought to expire 1526 quickly, user interface considerations may force service authors to resort to other 1527 means of preventing caching (e.g. "once-only" URLs) in order not to suffer the effects 1528 of improperly functioning history mechanisms.</t> 1529 </list> 1530 </t> 1531 </section> 1532 1533 1534 <section anchor="IANA.considerations" title="IANA Considerations"> 1535 1536 <section anchor="message.header.registration" title="Message Header Registration"> 1537 <t> 1538 The Message Header Registry located at <eref 1539 target="http://www.iana.org/assignments/message-headers/message-header-index.html" /> 1540 should be updated with the permanent registrations below (see <xref target="RFC3864" />): 1541 </t> 1542 1543 <!--AUTOGENERATED FROM extract-header-defs.xslt, do not edit manually--> 1544 <texttable align="left" anchor="iana.header.registration.table" suppress-title="true"> 1545 <ttcol>Header Field Name</ttcol> 1546 <ttcol>Protocol</ttcol> 1547 <ttcol>Status</ttcol> 1548 <ttcol>Reference</ttcol> 1549 1550 <c>Age</c> 1551 <c>http</c> 1552 <c>standard</c> 1553 <c> 1554 <xref target="header.age" /> 1555 </c> 1556 1557 <c>Cache-Control</c> 1558 <c>http</c> 1559 <c>standard</c> 1560 <c> 1561 <xref target="header.cache-control" /> 1562 </c> 1563 1564 <c>Expires</c> 1565 <c>http</c> 1566 <c>standard</c> 1567 <c> 1568 <xref target="header.expires" /> 1569 </c> 1570 1571 <c>Pragma</c> 1572 <c>http</c> 1573 <c>standard</c> 1574 <c> 1575 <xref target="header.pragma" /> 1576 </c> 1577 1578 <c>Vary</c> 1579 <c>http</c> 1580 <c>standard</c> 1581 <c> 1582 <xref target="header.vary" /> 1583 </c> 1584 1585 <c>Warning</c> 1586 <c>http</c> 1587 <c>standard</c> 1588 <c> 1589 <xref target="header.warning" /> 1590 </c> 1591 </texttable> 1592 <!--(END)--> 1593 <t> 1594 The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force". 1595 </t> 1596 </section> 1597 1598 </section> 1599 1600 <section anchor="security.considerations" title="Security Considerations"> 1601 <t> 1602 Caches expose additional potential vulnerabilities, since the contents of the cache 1603 represent an attractive target for malicious exploitation. Because cache contents persist 1604 after an HTTP request is complete, an attack on the cache can reveal information long after 1605 a user believes that the information has been removed from the network. Therefore, cache 1606 contents should be protected as sensitive information. 1607 </t> 1608 </section> 1609 1610 <section anchor="ack" title="Acknowledgments"> 1611 <t> 1612 Much of the content and presentation of the caching design is due to suggestions and 1613 comments from individuals including: Shel Kaphan, Paul Leach, Koen Holtman, David Morris, 1614 and Larry Masinter. 1615 </t> 1616 </section> 1617 1618 </middle> 1619 1620 <back> 1621 <references title="Normative References"> 1622 1623 <reference anchor="ISO-8859-1"> 1624 <front> 1625 <title> Information technology -- 8-bit single-byte coded graphic character sets -- Part 1626 1: Latin alphabet No. 1 </title> 1627 <author> 1628 <organization>International Organization for Standardization</organization> 1629 </author> 1630 <date year="1998" /> 1631 </front> 1632 <seriesInfo name="ISO/IEC" value="8859-1:1998" /> 1633 </reference> 1634 1635 <reference anchor="Part1"> 1636 <front> 1637 <title abbrev="HTTP/1.1">HTTP/1.1, part 1: URIs, Connections, and Message Parsing</title> 1638 <author fullname="Roy T. Fielding" initials="R." role="editor" surname="Fielding"> 1639 <organization abbrev="Day Software">Day Software</organization> 1640 <address><email>fielding@gbiv.com</email></address> 1641 </author> 1642 <author fullname="Jim Gettys" initials="J." surname="Gettys"> 1643 <organization>One Laptop per Child</organization> 1644 <address><email>jg@laptop.org</email></address> 1645 </author> 1646 <author fullname="Jeffrey C. Mogul" initials="J." surname="Mogul"> 1647 <organization abbrev="HP">Hewlett-Packard Company</organization> 1648 <address><email>JeffMogul@acm.org</email></address> 1649 </author> 1650 <author fullname="Henrik Frystyk Nielsen" initials="H." surname="Frystyk"> 1651 <organization abbrev="Microsoft">Microsoft Corporation</organization> 1652 <address><email>henrikn@microsoft.com</email></address> 1653 </author> 1654 <author fullname="Larry Masinter" initials="L." surname="Masinter"> 1655 <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization> 1656 <address><email>LMM@acm.org</email></address> 1657 </author> 1658 <author fullname="Paul J. Leach" initials="P." surname="Leach"> 1659 <organization abbrev="Microsoft">Microsoft Corporation</organization> 1660 <address><email>paulle@microsoft.com</email></address> 1661 </author> 1662 <author fullname="Tim Berners-Lee" initials="T." surname="Berners-Lee"> 1663 <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> 1664 <address><email>timbl@w3.org</email></address> 1665 </author> 1666 <author fullname="Yves Lafon" initials="Y." role="editor" surname="Lafon"> 1667 <organization abbrev="W3C">World Wide Web Consortium</organization> 1668 <address><email>ylafon@w3.org</email></address> 1669 </author> 1670 <author fullname="Julian F. Reschke" initials="J. F." role="editor" surname="Reschke"> 1671 <organization abbrev="greenbytes">greenbytes GmbH</organization> 1672 <address><email>julian.reschke@greenbytes.de</email></address> 1673 </author> 1674 <date month="&ID-MONTH;" year="&ID-YEAR;" /> 1675 </front> 1676 <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p1-messaging-&ID-VERSION;" /> 1677 <x:source basename="p1-messaging" href="p1-messaging.xml" /> 1678 </reference> 1679 1680 <reference anchor="Part2"> 1681 <front> 1682 <title abbrev="HTTP/1.1">HTTP/1.1, part 2: Message Semantics</title> 1683 <author fullname="Roy T. Fielding" initials="R." role="editor" surname="Fielding"> 1684 <organization abbrev="Day Software">Day Software</organization> 1685 <address><email>fielding@gbiv.com</email></address> 1686 </author> 1687 <author fullname="Jim Gettys" initials="J." surname="Gettys"> 1688 <organization>One Laptop per Child</organization> 1689 <address><email>jg@laptop.org</email></address> 1690 </author> 1691 <author fullname="Jeffrey C. Mogul" initials="J." surname="Mogul"> 1692 <organization abbrev="HP">Hewlett-Packard Company</organization> 1693 <address><email>JeffMogul@acm.org</email></address> 1694 </author> 1695 <author fullname="Henrik Frystyk Nielsen" initials="H." surname="Frystyk"> 1696 <organization abbrev="Microsoft">Microsoft Corporation</organization> 1697 <address><email>henrikn@microsoft.com</email></address> 1698 </author> 1699 <author fullname="Larry Masinter" initials="L." surname="Masinter"> 1700 <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization> 1701 <address><email>LMM@acm.org</email></address> 1702 </author> 1703 <author fullname="Paul J. Leach" initials="P." surname="Leach"> 1704 <organization abbrev="Microsoft">Microsoft Corporation</organization> 1705 <address><email>paulle@microsoft.com</email></address> 1706 </author> 1707 <author fullname="Tim Berners-Lee" initials="T." surname="Berners-Lee"> 1708 <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> 1709 <address><email>timbl@w3.org</email></address> 1710 </author> 1711 <author fullname="Yves Lafon" initials="Y." role="editor" surname="Lafon"> 1712 <organization abbrev="W3C">World Wide Web Consortium</organization> 1713 <address><email>ylafon@w3.org</email></address> 1714 </author> 1715 <author fullname="Julian F. Reschke" initials="J. F." role="editor" surname="Reschke"> 1716 <organization abbrev="greenbytes">greenbytes GmbH</organization> 1717 <address><email>julian.reschke@greenbytes.de</email></address> 1718 </author> 1719 <date month="&ID-MONTH;" year="&ID-YEAR;" /> 1720 </front> 1721 <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p2-semantics-&ID-VERSION;" /> 1722 <x:source basename="p2-semantics" href="p2-semantics.xml" /> 1723 </reference> 1724 1725 <reference anchor="Part3"> 1726 <front> 1727 <title abbrev="HTTP/1.1">HTTP/1.1, part 3: Message Payload and Content Negotiation</title> 1728 <author fullname="Roy T. Fielding" initials="R." role="editor" surname="Fielding"> 1729 <organization abbrev="Day Software">Day Software</organization> 1730 <address><email>fielding@gbiv.com</email></address> 1731 </author> 1732 <author fullname="Jim Gettys" initials="J." surname="Gettys"> 1733 <organization>One Laptop per Child</organization> 1734 <address><email>jg@laptop.org</email></address> 1735 </author> 1736 <author fullname="Jeffrey C. Mogul" initials="J." surname="Mogul"> 1737 <organization abbrev="HP">Hewlett-Packard Company</organization> 1738 <address><email>JeffMogul@acm.org</email></address> 1739 </author> 1740 <author fullname="Henrik Frystyk Nielsen" initials="H." surname="Frystyk"> 1741 <organization abbrev="Microsoft">Microsoft Corporation</organization> 1742 <address><email>henrikn@microsoft.com</email></address> 1743 </author> 1744 <author fullname="Larry Masinter" initials="L." surname="Masinter"> 1745 <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization> 1746 <address><email>LMM@acm.org</email></address> 1747 </author> 1748 <author fullname="Paul J. Leach" initials="P." surname="Leach"> 1749 <organization abbrev="Microsoft">Microsoft Corporation</organization> 1750 <address><email>paulle@microsoft.com</email></address> 1751 </author> 1752 <author fullname="Tim Berners-Lee" initials="T." surname="Berners-Lee"> 1753 <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> 1754 <address><email>timbl@w3.org</email></address> 1755 </author> 1756 <author fullname="Yves Lafon" initials="Y." role="editor" surname="Lafon"> 1757 <organization abbrev="W3C">World Wide Web Consortium</organization> 1758 <address><email>ylafon@w3.org</email></address> 1759 </author> 1760 <author fullname="Julian F. Reschke" initials="J. F." role="editor" surname="Reschke"> 1761 <organization abbrev="greenbytes">greenbytes GmbH</organization> 1762 <address><email>julian.reschke@greenbytes.de</email></address> 1763 </author> 1764 <date month="&ID-MONTH;" year="&ID-YEAR;" /> 1765 </front> 1766 <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p3-payload-&ID-VERSION;" /> 1767 <x:source basename="p3-payload" href="p3-payload.xml" /> 1768 </reference> 1769 1770 <reference anchor="Part4"> 1771 <front> 1772 <title abbrev="HTTP/1.1">HTTP/1.1, part 4: Conditional Requests</title> 1773 <author fullname="Roy T. Fielding" initials="R." role="editor" surname="Fielding"> 1774 <organization abbrev="Day Software">Day Software</organization> 1775 <address><email>fielding@gbiv.com</email></address> 1776 </author> 1777 <author fullname="Jim Gettys" initials="J." surname="Gettys"> 1778 <organization>One Laptop per Child</organization> 1779 <address><email>jg@laptop.org</email></address> 1780 </author> 1781 <author fullname="Jeffrey C. Mogul" initials="J." surname="Mogul"> 1782 <organization abbrev="HP">Hewlett-Packard Company</organization> 1783 <address><email>JeffMogul@acm.org</email></address> 1784 </author> 1785 <author fullname="Henrik Frystyk Nielsen" initials="H." surname="Frystyk"> 1786 <organization abbrev="Microsoft">Microsoft Corporation</organization> 1787 <address><email>henrikn@microsoft.com</email></address> 1788 </author> 1789 <author fullname="Larry Masinter" initials="L." surname="Masinter"> 1790 <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization> 1791 <address><email>LMM@acm.org</email></address> 1792 </author> 1793 <author fullname="Paul J. Leach" initials="P." surname="Leach"> 1794 <organization abbrev="Microsoft">Microsoft Corporation</organization> 1795 <address><email>paulle@microsoft.com</email></address> 1796 </author> 1797 <author fullname="Tim Berners-Lee" initials="T." surname="Berners-Lee"> 1798 <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> 1799 <address><email>timbl@w3.org</email></address> 1800 </author> 1801 <author fullname="Yves Lafon" initials="Y." role="editor" surname="Lafon"> 1802 <organization abbrev="W3C">World Wide Web Consortium</organization> 1803 <address><email>ylafon@w3.org</email></address> 1804 </author> 1805 <author fullname="Julian F. Reschke" initials="J. F." role="editor" surname="Reschke"> 1806 <organization abbrev="greenbytes">greenbytes GmbH</organization> 1807 <address><email>julian.reschke@greenbytes.de</email></address> 1808 </author> 1809 <date month="&ID-MONTH;" year="&ID-YEAR;" /> 1810 </front> 1811 <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p4-conditional-&ID-VERSION;" /> 1812 <x:source basename="p4-conditional" href="p4-conditional.xml" /> 1813 </reference> 1814 1815 <reference anchor="Part5"> 1816 <front> 1817 <title abbrev="HTTP/1.1">HTTP/1.1, part 5: Range Requests and Partial Responses</title> 1818 <author fullname="Roy T. Fielding" initials="R." role="editor" surname="Fielding"> 1819 <organization abbrev="Day Software">Day Software</organization> 1820 <address><email>fielding@gbiv.com</email></address> 1821 </author> 1822 <author fullname="Jim Gettys" initials="J." surname="Gettys"> 1823 <organization>One Laptop per Child</organization> 1824 <address><email>jg@laptop.org</email></address> 1825 </author> 1826 <author fullname="Jeffrey C. Mogul" initials="J." surname="Mogul"> 1827 <organization abbrev="HP">Hewlett-Packard Company</organization> 1828 <address><email>JeffMogul@acm.org</email></address> 1829 </author> 1830 <author fullname="Henrik Frystyk Nielsen" initials="H." surname="Frystyk"> 1831 <organization abbrev="Microsoft">Microsoft Corporation</organization> 1832 <address><email>henrikn@microsoft.com</email></address> 1833 </author> 1834 <author fullname="Larry Masinter" initials="L." surname="Masinter"> 1835 <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization> 1836 <address><email>LMM@acm.org</email></address> 1837 </author> 1838 <author fullname="Paul J. Leach" initials="P." surname="Leach"> 1839 <organization abbrev="Microsoft">Microsoft Corporation</organization> 1840 <address><email>paulle@microsoft.com</email></address> 1841 </author> 1842 <author fullname="Tim Berners-Lee" initials="T." surname="Berners-Lee"> 1843 <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> 1844 <address><email>timbl@w3.org</email></address> 1845 </author> 1846 <author fullname="Yves Lafon" initials="Y." role="editor" surname="Lafon"> 1847 <organization abbrev="W3C">World Wide Web Consortium</organization> 1848 <address><email>ylafon@w3.org</email></address> 1849 </author> 1850 <author fullname="Julian F. Reschke" initials="J. F." role="editor" surname="Reschke"> 1851 <organization abbrev="greenbytes">greenbytes GmbH</organization> 1852 <address><email>julian.reschke@greenbytes.de</email></address> 1853 </author> 1854 <date month="&ID-MONTH;" year="&ID-YEAR;" /> 1855 </front> 1856 <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p5-range-&ID-VERSION;" /> 1857 <x:source basename="p5-range" href="p5-range.xml" /> 1858 </reference> 1859 1860 <reference anchor="Part7"> 1861 <front> 1862 <title abbrev="HTTP/1.1">HTTP/1.1, part 7: Authentication</title> 1863 <author fullname="Roy T. Fielding" initials="R." role="editor" surname="Fielding"> 1864 <organization abbrev="Day Software">Day Software</organization> 1865 <address><email>fielding@gbiv.com</email></address> 1866 </author> 1867 <author fullname="Jim Gettys" initials="J." surname="Gettys"> 1868 <organization>One Laptop per Child</organization> 1869 <address><email>jg@laptop.org</email></address> 1870 </author> 1871 <author fullname="Jeffrey C. Mogul" initials="J." surname="Mogul"> 1872 <organization abbrev="HP">Hewlett-Packard Company</organization> 1873 <address><email>JeffMogul@acm.org</email></address> 1874 </author> 1875 <author fullname="Henrik Frystyk Nielsen" initials="H." surname="Frystyk"> 1876 <organization abbrev="Microsoft">Microsoft Corporation</organization> 1877 <address><email>henrikn@microsoft.com</email></address> 1878 </author> 1879 <author fullname="Larry Masinter" initials="L." surname="Masinter"> 1880 <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization> 1881 <address><email>LMM@acm.org</email></address> 1882 </author> 1883 <author fullname="Paul J. Leach" initials="P." surname="Leach"> 1884 <organization abbrev="Microsoft">Microsoft Corporation</organization> 1885 <address><email>paulle@microsoft.com</email></address> 1886 </author> 1887 <author fullname="Tim Berners-Lee" initials="T." surname="Berners-Lee"> 1888 <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> 1889 <address><email>timbl@w3.org</email></address> 1890 </author> 1891 <author fullname="Yves Lafon" initials="Y." role="editor" surname="Lafon"> 1892 <organization abbrev="W3C">World Wide Web Consortium</organization> 1893 <address><email>ylafon@w3.org</email></address> 1894 </author> 1895 <author fullname="Julian F. Reschke" initials="J. F." role="editor" surname="Reschke"> 1896 <organization abbrev="greenbytes">greenbytes GmbH</organization> 1897 <address><email>julian.reschke@greenbytes.de</email></address> 1898 </author> 1899 <date month="&ID-MONTH;" year="&ID-YEAR;" /> 1900 </front> 1901 <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p7-auth-&ID-VERSION;" /> 1902 <x:source basename="p7-auth" href="p7-auth.xml" /> 1903 </reference> 1904 1905 <reference anchor="RFC2047"> 1906 <front> 1907 <title abbrev="Message Header Extensions">MIME (Multipurpose Internet Mail Extensions) 1908 Part Three: Message Header Extensions for Non-ASCII Text</title> 1909 <author fullname="Keith Moore" initials="K." surname="Moore"> 1910 <organization>University of Tennessee</organization> 1911 <address><email>moore@cs.utk.edu</email></address> 1912 </author> 1913 <date month="November" year="1996" /> 1914 </front> 1915 <seriesInfo name="RFC" value="2047" /> 1916 </reference> 1917 1918 <reference anchor="RFC2119"> 1919 <front> 1920 <title>Key words for use in RFCs to Indicate Requirement Levels</title> 1921 <author fullname="Scott Bradner" initials="S." surname="Bradner"> 1922 <organization>Harvard University</organization> 1923 <address><email>sob@harvard.edu</email></address> 1924 </author> 1925 <date month="March" year="1997" /> 1926 </front> 1927 <seriesInfo name="BCP" value="14" /> 1928 <seriesInfo name="RFC" value="2119" /> 1929 </reference> 1930 1931 <reference anchor="RFC5234"> 1932 <front> 1933 <title abbrev="ABNF for Syntax Specifications">Augmented BNF for Syntax Specifications: ABNF</title> 1934 <author initials="D." surname="Crocker" fullname="Dave Crocker" role="editor"> 1935 <organization>Brandenburg InternetWorking</organization> 1936 <address> 1937 <postal> 1938 <street>675 Spruce Dr.</street> 1939 <city>Sunnyvale</city> 1940 <region>CA</region> 1941 <code>94086</code> 1942 <country>US</country></postal> 1943 <phone>+1.408.246.8253</phone> 1944 <email>dcrocker@bbiw.net</email></address> 1945 </author> 1946 <author initials="P." surname="Overell" fullname="Paul Overell"> 1947 <organization>THUS plc.</organization> 1948 <address> 1949 <postal> 1950 <street>1/2 Berkeley Square</street> 1951 <street>99 Berkely Street</street> 1952 <city>Glasgow</city> 1953 <code>G3 7HR</code> 1954 <country>UK</country></postal> 1955 <email>paul.overell@thus.net</email></address> 1956 </author> 1957 <date month="January" year="2008"/> 1958 </front> 1959 <seriesInfo name="STD" value="68"/> 1960 <seriesInfo name="RFC" value="5234"/> 1961 </reference> 1962 1963 </references> 1964 1965 <references title="Informative References"> 1966 1967 <reference anchor="RFC1305"> 1968 <front> 1969 <title>Network Time Protocol (Version 3) Specification, Implementation</title> 1970 <author fullname="David L. Mills" initials="D." surname="Mills"> 1971 <organization>University of Delaware, Electrical Engineering Department</organization> 1972 <address><email>mills@udel.edu</email></address> 1973 </author> 1974 <date month="March" year="1992" /> 1975 </front> 1976 <seriesInfo name="RFC" value="1305" /> 1977 </reference> 1978 1979 <reference anchor="RFC2616"> 1980 <front> 1981 <title>Hypertext Transfer Protocol -- HTTP/1.1</title> 1982 <author fullname="R. Fielding" initials="R." surname="Fielding"> 1983 <organization>University of California, Irvine</organization> 1984 <address><email>fielding@ics.uci.edu</email></address> 1985 </author> 1986 <author fullname="J. Gettys" initials="J." surname="Gettys"> 1987 <organization>W3C</organization> 1988 <address><email>jg@w3.org</email></address> 1989 </author> 1990 <author fullname="J. Mogul" initials="J." surname="Mogul"> 1991 <organization>Compaq Computer Corporation</organization> 1992 <address><email>mogul@wrl.dec.com</email></address> 1993 </author> 1994 <author fullname="H. Frystyk" initials="H." surname="Frystyk"> 1995 <organization>MIT Laboratory for Computer Science</organization> 1996 <address><email>frystyk@w3.org</email></address> 1997 </author> 1998 <author fullname="L. Masinter" initials="L." surname="Masinter"> 1999 <organization>Xerox Corporation</organization> 2000 <address><email>masinter@parc.xerox.com</email></address> 2001 </author> 2002 <author fullname="P. Leach" initials="P." surname="Leach"> 2003 <organization>Microsoft Corporation</organization> 2004 <address><email>paulle@microsoft.com</email></address> 2005 </author> 2006 <author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee"> 2007 <organization>W3C</organization> 2008 <address><email>timbl@w3.org</email></address> 2009 </author> 2010 <date month="June" year="1999" /> 2011 </front> 2012 <seriesInfo name="RFC" value="2616" /> 2013 </reference> 2014 2015 <reference anchor="RFC3864"> 2016 <front> 2017 <title>Registration Procedures for Message Header Fields</title> 2018 <author fullname="G. Klyne" initials="G." surname="Klyne"> 2019 <organization>Nine by Nine</organization> 2020 <address><email>GK-IETF@ninebynine.org</email></address> 2021 </author> 2022 <author fullname="M. Nottingham" initials="M." surname="Nottingham"> 2023 <organization>BEA Systems</organization> 2024 <address><email>mnot@pobox.com</email></address> 2025 </author> 2026 <author fullname="J. Mogul" initials="J." surname="Mogul"> 2027 <organization>HP Labs</organization> 2028 <address><email>JeffMogul@acm.org</email></address> 2029 </author> 2030 <date month="September" year="2004" /> 2031 </front> 2032 <seriesInfo name="BCP" value="90" /> 2033 <seriesInfo name="RFC" value="3864" /> 2034 </reference> 2035 2036 </references> 2037 2038 <section anchor="compatibility" title="Compatibility with Previous Versions"> 2039 2040 <section anchor="changes.from.rfc.2068" title="Changes from RFC 2068"> 2041 <t> 2042 A case was missed in the Cache-Control model of HTTP/1.1; s-maxage was introduced to add 2043 this missing case. 2044 (Sections <xref format="counter" target="response.cacheability" />, <xref format="counter" target="header.cache-control" />). 2045 </t> 2046 <t> 2047 Transfer-coding and message lengths all interact in ways that required fixing exactly 2048 when chunked encoding is used (to allow for transfer encoding that may not be self 2049 delimiting); it was important to straighten out exactly how message lengths are computed. 2050 (see also <xref target="Part1" />, <xref target="Part3" /> and <xref target="Part5" />) 2051 <cref source="jre">This used to refer to the text about non-modifiable headers, and will have to be updated later on.</cref> 2052 </t> 2053 <t> 2054 Proxies should be able to add Content-Length when appropriate. 2055 <cref source="jre">This used to refer to the text about non-modifiable headers, and will have to be updated later on.</cref> 2056 </t> 2057 <t 2058 >Range request responses would become very verbose if all meta-data were always returned; 2059 by allowing the server to only send needed headers in a 206 response, this problem can be 2060 avoided. 2061 (<xref target="combining.headers" />) 2062 </t> 2063 <t> 2064 The Cache-Control: max-age directive was not properly defined for responses. 2065 (<xref target="cache-response-directive"/>) 2066 </t> 2067 <t> 2068 Warnings could be cached incorrectly, or not updated appropriately. (Section <xref 2069 format="counter" target="expiration.model" />, <xref format="counter" 2070 target="combining.headers" />, <xref format="counter" target="header.cache-control" />, 2071 and <xref format="counter" target="header.warning" />) Warning also needed to be a general 2072 header, as PUT or other methods may have need for it in requests. 2073 </t> 2074 </section> 2075 2076 <section anchor="changes.from.rfc.2616" title="Changes from RFC 2616"> 2077 <t> 2078 Clarify denial of service attack avoidance requirement. 2079 (<xref target="invalidation.after.updates.or.deletions" />) 2080 </t> 2081 </section> 1837 2082 1838 2083 </section> … … 1915 2160 </artwork></figure></section> 1916 2161 1917 <section anchor="change.log" title="Change Log (to be removed by RFC Editor before publication)"> 1918 1919 <section title="Since RFC2616"> 1920 <t>Extracted relevant partitions from <xref target="RFC2616" />.</t> 1921 </section> 1922 1923 <section title="Since draft-ietf-httpbis-p6-cache-00"> 1924 <t>Closed issues: <list style="symbols"> 1925 <t> 1926 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/9" />: "Trailer" 1927 (<eref target="http://purl.org/NET/http-errata#trailer-hop" />)</t> 1928 <t> 1929 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/12" />: "Invalidation 1930 after Update or Delete" (<eref target="http://purl.org/NET/http-errata#invalidupd" />)</t> 1931 <t> 1932 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/35" />: "Normative and 1933 Informative references"</t> 1934 <t> 1935 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/48" />: "Date 1936 reference typo"</t> 1937 <t> 1938 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/49" />: "Connection 1939 header text"</t> 1940 <t> 1941 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/65" />: "Informative 1942 references"</t> 1943 <t> 1944 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/66" />: "ISO-8859-1 1945 Reference"</t> 1946 <t> 1947 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/86" />: "Normative 1948 up-to-date references"</t> 1949 <t> 1950 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/87" />: "typo in 1951 13.2.2"</t> 1952 </list> 1953 </t> 1954 <t>Other changes: <list style="symbols"> 1955 <t>Use names of RFC4234 core rules DQUOTE and HTAB (work in progress on <eref 1956 target="http://tools.ietf.org/wg/httpbis/trac/ticket/36" />)</t> 1957 </list> 1958 </t> 1959 </section> 1960 1961 <section title="Since draft-ietf-httpbis-p6-cache-01"> 1962 <t>Closed issues: <list style="symbols"> 1963 <t> 1964 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/82" />: "rel_path not 1965 used"</t> 1966 </list> 1967 </t> 1968 <t>Other changes: <list style="symbols"> 1969 <t>Get rid of duplicate BNF rule names ("host" -> "uri-host") (work in progress 1970 on <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36" />)</t> 1971 <t>Add explicit references to BNF syntax and rules imported from other parts of the 1972 specification.</t> 1973 </list> 1974 </t> 1975 </section> 1976 1977 <section anchor="changes.since.02" title="Since draft-ietf-httpbis-p6-cache-02"> 1978 <t>Ongoing work on IANA Message Header Registration (<eref 1979 target="http://tools.ietf.org/wg/httpbis/trac/ticket/40" />): <list style="symbols"> 1980 <t>Reference RFC 3984, and update header registrations for headers defined in this 1981 document.</t> 1982 </list> 1983 </t> 1984 </section> 1985 1986 <section anchor="changes.since.03" title="Since draft-ietf-httpbis-p6-cache-03"> 1987 <t>Closed issues: <list style="symbols"> 1988 <t> 1989 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/106" />: "Vary header 1990 classification"</t> 1991 </list> 1992 </t> 1993 </section> 1994 1995 <section anchor="changes.since.04" title="Since draft-ietf-httpbis-p6-cache-04"> 1996 <t> 1997 Ongoing work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>): 1998 <list style="symbols"> 1999 <t> 2000 Use "/" instead of "|" for alternatives. 2001 </t> 2002 <t> 2003 Introduce new ABNF rules for "bad" whitespace ("BWS"), optional 2004 whitespace ("OWS") and required whitespace ("RWS"). 2005 </t> 2006 <t> 2007 Rewrite ABNFs to spell out whitespace rules, factor out 2008 header value format definitions. 2009 </t> 2010 </list> 2011 </t> 2012 </section> 2013 2014 <section anchor="changes.since.05" title="Since draft-ietf-httpbis-p6-cache-05"> 2015 <t> 2016 This is a total rewrite of this part of the specification. 2017 </t> 2018 <t> 2019 In addition: Ongoing work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>): 2020 <list style="symbols"> 2021 <t> 2022 Add appendix containing collected and expanded ABNF, reorganize ABNF introduction. 2023 </t> 2024 </list> 2025 </t> 2026 </section> 2027 2028 </section> 2162 <section anchor="change.log" title="Change Log (to be removed by RFC Editor before publication)"> 2163 2164 <section title="Since RFC2616"> 2165 <t>Extracted relevant partitions from <xref target="RFC2616" />.</t> 2166 </section> 2167 2168 <section title="Since draft-ietf-httpbis-p6-cache-00"> 2169 <t> 2170 Closed issues: 2171 <list style="symbols"> 2172 <t> 2173 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/9" />: "Trailer" 2174 (<eref target="http://purl.org/NET/http-errata#trailer-hop" />)</t> 2175 <t> 2176 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/12" />: "Invalidation after Update or Delete" (<eref target="http://purl.org/NET/http-errata#invalidupd" />)</t> 2177 <t> 2178 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/35" />: "Normative and Informative references"</t> 2179 <t> 2180 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/48" />: "Date reference typo"</t> 2181 <t> 2182 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/49" />: "Connection header text"</t> 2183 <t> 2184 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/65" />: "Informative references"</t> 2185 <t> 2186 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/66" />: "ISO-8859-1 Reference"</t> 2187 <t> 2188 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/86" />: "Normative up-to-date references"</t> 2189 <t> 2190 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/87" />: "typo in 13.2.2"</t> 2191 </list> 2192 </t> 2193 <t> 2194 Other changes: 2195 <list style="symbols"> 2196 <t>Use names of RFC4234 core rules DQUOTE and HTAB (work in progress on <eref 2197 target="http://tools.ietf.org/wg/httpbis/trac/ticket/36" />)</t> 2198 </list> 2199 </t> 2200 </section> 2201 2202 <section title="Since draft-ietf-httpbis-p6-cache-01"> 2203 <t> 2204 Closed issues: 2205 <list style="symbols"> 2206 <t> 2207 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/82" />: "rel_path not used"</t> 2208 </list> 2209 </t> 2210 <t> 2211 Other changes: 2212 <list style="symbols"> 2213 <t>Get rid of duplicate BNF rule names ("host" -> "uri-host") (work in progress 2214 on <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36" />)</t> 2215 <t>Add explicit references to BNF syntax and rules imported from other parts of the 2216 specification.</t> 2217 </list> 2218 </t> 2219 </section> 2220 2221 <section anchor="changes.since.02" title="Since draft-ietf-httpbis-p6-cache-02"> 2222 <t> 2223 Ongoing work on IANA Message Header Registration (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/40" />): 2224 <list style="symbols"> 2225 <t>Reference RFC 3984, and update header registrations for headers defined in this 2226 document.</t> 2227 </list> 2228 </t> 2229 </section> 2230 2231 <section anchor="changes.since.03" title="Since draft-ietf-httpbis-p6-cache-03"> 2232 <t> 2233 Closed issues: 2234 <list style="symbols"> 2235 <t> 2236 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/106" />: "Vary header classification"</t> 2237 </list> 2238 </t> 2239 </section> 2240 2241 <section anchor="changes.since.04" title="Since draft-ietf-httpbis-p6-cache-04"> 2242 <t> 2243 Ongoing work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>): 2244 <list style="symbols"> 2245 <t> 2246 Use "/" instead of "|" for alternatives. 2247 </t> 2248 <t> 2249 Introduce new ABNF rules for "bad" whitespace ("BWS"), optional 2250 whitespace ("OWS") and required whitespace ("RWS"). 2251 </t> 2252 <t> 2253 Rewrite ABNFs to spell out whitespace rules, factor out 2254 header value format definitions. 2255 </t> 2256 </list> 2257 </t> 2258 </section> 2259 2260 <section anchor="changes.since.05" title="Since draft-ietf-httpbis-p6-cache-05"> 2261 <t> 2262 This is a total rewrite of this part of the specification. 2263 </t> 2264 <t> 2265 In addition: Ongoing work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>): 2266 <list style="symbols"> 2267 <t> 2268 Add appendix containing collected and expanded ABNF, reorganize ABNF introduction. 2269 </t> 2270 </list> 2271 </t> 2272 </section> 2273 2274 </section> 2029 2275 </back> 2030 2276 </rfc> -
draft-ietf-httpbis/latest/p7-auth.html
r538 r540 462 462 <tr> 463 463 <td class="header left"></td> 464 <td class="header right">March 5, 2009</td>464 <td class="header right">March 6, 2009</td> 465 465 </tr> 466 466 </table>
Note: See TracChangeset
for help on using the changeset viewer.