Changeset 1554 for draft-ietf-httpbis/latest/p6-cache.html
- Timestamp:
- 03/03/12 00:16:57 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p6-cache.html
r1552 r1554 463 463 } 464 464 @bottom-center { 465 content: "Expires September 2012";465 content: "Expires September 4, 2012"; 466 466 } 467 467 @bottom-right { … … 498 498 <link href="p5-range.html" rel="prev"> 499 499 <link href="p7-auth.html" rel="next"> 500 <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.570, 2012-02-13 19:17:35, XSLT vendor: SAXON 8.9from Saxonica http://www.saxonica.com/">500 <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.570, 2012-02-13 19:17:35, XSLT vendor: SAXON 9.1.0.8 from Saxonica http://www.saxonica.com/"> 501 501 <link rel="schema.dct" href="http://purl.org/dc/terms/"> 502 502 <meta name="dct.creator" content="Fielding, R."> … … 511 511 <meta name="dct.creator" content="Reschke, J. F."> 512 512 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest"> 513 <meta name="dct.issued" scheme="ISO8601" content="2012-03 ">513 <meta name="dct.issued" scheme="ISO8601" content="2012-03-03"> 514 514 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 515 515 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 6 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 6 defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages."> … … 537 537 </tr> 538 538 <tr> 539 <td class="left">Expires: September 2012</td>539 <td class="left">Expires: September 4, 2012</td> 540 540 <td class="right">J. Mogul</td> 541 541 </tr> … … 602 602 <tr> 603 603 <td class="left"></td> 604 <td class="right">March 2012</td>604 <td class="right">March 3, 2012</td> 605 605 </tr> 606 606 </tbody> … … 632 632 in progress”. 633 633 </p> 634 <p>This Internet-Draft will expire in September2012.</p>634 <p>This Internet-Draft will expire on September 4, 2012.</p> 635 635 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 636 636 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 675 675 </li> 676 676 <li>2.4 <a href="#validation.model">Validation Model</a><ul> 677 <li>2.4.1 <a href="#freshening.responses">Freshening Responses </a></li>677 <li>2.4.1 <a href="#freshening.responses">Freshening Responses with 304 Not Modified</a></li> 678 678 </ul> 679 679 </li> 680 <li>2.5 <a href="#invalidation.after.updates.or.deletions">Request Methods that Invalidate</a></li> 681 <li>2.6 <a href="#caching.authenticated.responses">Shared Caching of Authenticated Responses</a></li> 682 <li>2.7 <a href="#caching.negotiated.responses">Caching Negotiated Responses</a></li> 683 <li>2.8 <a href="#combining.responses">Combining Partial Content</a></li> 680 <li>2.5 <a href="#head.effects">Updating Caches with HEAD Responses</a></li> 681 <li>2.6 <a href="#invalidation.after.updates.or.deletions">Request Methods that Invalidate</a></li> 682 <li>2.7 <a href="#caching.authenticated.responses">Shared Caching of Authenticated Responses</a></li> 683 <li>2.8 <a href="#caching.negotiated.responses">Caching Negotiated Responses</a></li> 684 <li>2.9 <a href="#combining.responses">Combining Partial Content</a></li> 684 685 </ul> 685 686 </li> … … 904 905 </p> 905 906 <p id="rfc.section.2.p.4">If a request target is subject to content negotiation, its cache entry might consist of multiple stored responses, each differentiated 906 by a secondary key for the values of the original request's selecting header fields (<a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section 2. 7</a>).907 by a secondary key for the values of the original request's selecting header fields (<a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section 2.8</a>). 907 908 </p> 908 909 <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a> <a id="response.cacheability" href="#response.cacheability">Response Cacheability</a></h2> … … 916 917 <li>the "private" cache response directive (see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section 3.2.2</a>) does not appear in the response, if the cache is shared, and 917 918 </li> 918 <li>the "Authorization" header field (see <a href="p7-auth.html#header.authorization" title="Authorization">Section 4.1</a> of <a href="#Part7" id="rfc.xref.Part7.1"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>) does not appear in the request, if the cache is shared, unless the response explicitly allows it (see <a href="#caching.authenticated.responses" title="Shared Caching of Authenticated Responses">Section 2. 6</a>), and919 <li>the "Authorization" header field (see <a href="p7-auth.html#header.authorization" title="Authorization">Section 4.1</a> of <a href="#Part7" id="rfc.xref.Part7.1"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>) does not appear in the request, if the cache is shared, unless the response explicitly allows it (see <a href="#caching.authenticated.responses" title="Shared Caching of Authenticated Responses">Section 2.7</a>), and 919 920 </li> 920 921 <li>the response either: … … 945 946 not understand the range units used in those fields. 946 947 </p> 947 <p id="rfc.section.2.1.p.6">A cache <em class="bcp14">MAY</em> complete a stored incomplete response by making a subsequent range request (<a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) and combining the successful response with the stored entry, as defined in <a href="#combining.responses" title="Combining Partial Content">Section 2. 8</a>. A cache <em class="bcp14">MUST NOT</em> use an incomplete response to answer requests unless the response has been made complete or the request is partial and specifies948 <p id="rfc.section.2.1.p.6">A cache <em class="bcp14">MAY</em> complete a stored incomplete response by making a subsequent range request (<a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) and combining the successful response with the stored entry, as defined in <a href="#combining.responses" title="Combining Partial Content">Section 2.9</a>. A cache <em class="bcp14">MUST NOT</em> use an incomplete response to answer requests unless the response has been made complete or the request is partial and specifies 948 949 a range that is wholly within the incomplete response. A cache <em class="bcp14">MUST NOT</em> send a partial response to a client without explicitly marking it as such using the 206 (Partial Content) status code. 949 950 </p> … … 955 956 </li> 956 957 <li>the request method associated with the stored response allows it to be used for the presented request, and</li> 957 <li>selecting header fields nominated by the stored response (if any) match those presented (see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section 2. 7</a>), and958 <li>selecting header fields nominated by the stored response (if any) match those presented (see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section 2.8</a>), and 958 959 </li> 959 960 <li>the presented request does not contain the no-cache pragma (<a href="#header.pragma" id="rfc.xref.header.pragma.1" title="Pragma">Section 3.4</a>), nor the no-cache cache directive (<a href="#cache-request-directive" title="Request Cache-Control Directives">Section 3.2.1</a>), unless the stored response is successfully validated (<a href="#validation.model" title="Validation Model">Section 2.4</a>), and … … 979 980 having received a corresponding response. 980 981 </p> 981 <p id="rfc.section.2.2.p.5">Also, note that unsafe requests might invalidate already stored responses; see <a href="#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section 2. 5</a>.982 <p id="rfc.section.2.2.p.5">Also, note that unsafe requests might invalidate already stored responses; see <a href="#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section 2.6</a>. 982 983 </p> 983 984 <p id="rfc.section.2.2.p.6">When more than one suitable response is stored, a cache <em class="bcp14">MUST</em> use the most recent response (as determined by the Date header field). It can also forward a request with "Cache-Control: … … 1136 1137 <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a> <a id="validation.model" href="#validation.model">Validation Model</a></h2> 1137 1138 <p id="rfc.section.2.4.p.1">When a cache has one or more stored responses for a requested URI, but cannot serve any of them (e.g., because they are not 1138 fresh, or one cannot be selected; see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section 2. 7</a>), it can use the conditional request mechanism <a href="#Part4" id="rfc.xref.Part4.5"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a> in the forwarded request to give the origin server an opportunity to both select a valid stored response to be used, and to1139 fresh, or one cannot be selected; see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section 2.8</a>), it can use the conditional request mechanism <a href="#Part4" id="rfc.xref.Part4.5"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a> in the forwarded request to give the origin server an opportunity to both select a valid stored response to be used, and to 1139 1140 update it. This process is known as "validating" or "revalidating" the stored response. 1140 1141 </p> 1141 1142 <p id="rfc.section.2.4.p.2">When sending such a conditional request, a cache adds an If-Modified-Since header field whose value is that of the Last-Modified 1142 header field from the selected (see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section 2. 7</a>) stored response, if available.1143 header field from the selected (see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section 2.8</a>) stored response, if available. 1143 1144 </p> 1144 1145 <p id="rfc.section.2.4.p.3">Additionally, a cache can add an If-None-Match header field whose value is that of the ETag header field(s) from all responses … … 1150 1151 <p id="rfc.section.2.4.p.5"> </p> 1151 1152 <ul> 1152 <li>A 304 (Not Modified) response status code indicates that the stored response can be updated and reused; see <a href="#freshening.responses" title="Freshening Responses ">Section 2.4.1</a>.1153 <li>A 304 (Not Modified) response status code indicates that the stored response can be updated and reused; see <a href="#freshening.responses" title="Freshening Responses with 304 Not Modified">Section 2.4.1</a>. 1153 1154 </li> 1154 1155 <li>A full response (i.e., one with a response body) indicates that none of the stored responses nominated in the conditional … … 1160 1161 </li> 1161 1162 </ul> 1162 <h3 id="rfc.section.2.4.1"><a href="#rfc.section.2.4.1">2.4.1</a> <a id="freshening.responses" href="#freshening.responses">Freshening Responses </a></h3>1163 <h3 id="rfc.section.2.4.1"><a href="#rfc.section.2.4.1">2.4.1</a> <a id="freshening.responses" href="#freshening.responses">Freshening Responses with 304 Not Modified</a></h3> 1163 1164 <p id="rfc.section.2.4.1.p.1">When a cache receives a 304 (Not Modified) response and already has one or more stored 200 (OK) responses for the same cache 1164 1165 key, the cache needs to identify which of the stored responses are updated by this new response and then update the stored … … 1187 1188 </li> 1188 1189 </ul> 1189 <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a> <a id="invalidation.after.updates.or.deletions" href="#invalidation.after.updates.or.deletions">Request Methods that Invalidate</a></h2> 1190 <p id="rfc.section.2.5.p.1">Because unsafe request methods (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 6.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) such as PUT, POST or DELETE have the potential for changing state on the origin server, intervening caches can use them 1190 <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a> <a id="head.effects" href="#head.effects">Updating Caches with HEAD Responses</a></h2> 1191 <p id="rfc.section.2.5.p.1">A response to the HEAD method is identical to what an equivalent request made with a GET would have been, except it lacks 1192 a body. This property of HEAD responses is used to both invalidate and update cached GET responses. 1193 </p> 1194 <p id="rfc.section.2.5.p.2">If one or more stored GET responses can be selected (as per <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section 2.8</a>) for a HEAD request, and the Content-Length, ETag or Last-Modified value of a HEAD response differs from that in a selected 1195 GET response, the cache <em class="bcp14">MUST</em> consider that selected response to be stale. 1196 </p> 1197 <p id="rfc.section.2.5.p.3">If the Content-Length, ETag and Last-Modified values of a HEAD response (when present) are the same as that in a selected 1198 GET response (as per <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section 2.8</a>), the cache SHOULD update the remaining headers in the stored response using the following rules: 1199 </p> 1200 <ul> 1201 <li>delete any Warning header fields in the stored response with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.3" title="Warning">Section 3.6</a>); 1202 </li> 1203 <li>retain any Warning header fields in the stored response with warn-code 2xx; and,</li> 1204 <li>use other header fields provided in the response to replace all instances of the corresponding header fields in the stored 1205 response. 1206 </li> 1207 </ul> 1208 <h2 id="rfc.section.2.6"><a href="#rfc.section.2.6">2.6</a> <a id="invalidation.after.updates.or.deletions" href="#invalidation.after.updates.or.deletions">Request Methods that Invalidate</a></h2> 1209 <p id="rfc.section.2.6.p.1">Because unsafe request methods (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 6.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) such as PUT, POST or DELETE have the potential for changing state on the origin server, intervening caches can use them 1191 1210 to keep their contents up-to-date. 1192 1211 </p> 1193 <p id="rfc.section.2. 5.p.2">A cache <em class="bcp14">MUST</em> invalidate the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) as well as the URI(s) in the Location and Content-Location response header fields (if present) when a non-error response1212 <p id="rfc.section.2.6.p.2">A cache <em class="bcp14">MUST</em> invalidate the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) as well as the URI(s) in the Location and Content-Location response header fields (if present) when a non-error response 1194 1213 to a request with an unsafe method is received. 1195 1214 </p> 1196 <p id="rfc.section.2. 5.p.3">However, a cache <em class="bcp14">MUST NOT</em> invalidate a URI from a Location or Content-Location response header field if the host part of that URI differs from the host1215 <p id="rfc.section.2.6.p.3">However, a cache <em class="bcp14">MUST NOT</em> invalidate a URI from a Location or Content-Location response header field if the host part of that URI differs from the host 1197 1216 part in the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). This helps prevent denial of service attacks. 1198 1217 </p> 1199 <p id="rfc.section.2. 5.p.4">A cache <em class="bcp14">MUST</em> invalidate the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) when it receives a non-error response to a request with a method whose safety is unknown.1200 </p> 1201 <p id="rfc.section.2. 5.p.5">Here, a "non-error response" is one with a 2xx or 3xx status code. "Invalidate" means that the cache will either remove all1218 <p id="rfc.section.2.6.p.4">A cache <em class="bcp14">MUST</em> invalidate the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) when it receives a non-error response to a request with a method whose safety is unknown. 1219 </p> 1220 <p id="rfc.section.2.6.p.5">Here, a "non-error response" is one with a 2xx or 3xx status code. "Invalidate" means that the cache will either remove all 1202 1221 stored responses related to the effective request URI, or will mark these as "invalid" and in need of a mandatory validation 1203 1222 before they can be returned in response to a subsequent request. 1204 1223 </p> 1205 <p id="rfc.section.2. 5.p.6">Note that this does not guarantee that all appropriate responses are invalidated. For example, the request that caused the1224 <p id="rfc.section.2.6.p.6">Note that this does not guarantee that all appropriate responses are invalidated. For example, the request that caused the 1206 1225 change at the origin server might not have gone through the cache where a response is stored. 1207 1226 </p> 1208 <h2 id="rfc.section.2. 6"><a href="#rfc.section.2.6">2.6</a> <a id="caching.authenticated.responses" href="#caching.authenticated.responses">Shared Caching of Authenticated Responses</a></h2>1209 <p id="rfc.section.2. 6.p.1">A shared cache <em class="bcp14">MUST NOT</em> use a cached response to a request with an Authorization header field (<a href="p7-auth.html#header.authorization" title="Authorization">Section 4.1</a> of <a href="#Part7" id="rfc.xref.Part7.2"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>) to satisfy any subsequent request unless a cache directive that allows such responses to be stored is present in the response.1210 </p> 1211 <p id="rfc.section.2. 6.p.2">In this specification, the following Cache-Control response directives (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section 3.2.2</a>) have such an effect: must-revalidate, public, s-maxage.1212 </p> 1213 <p id="rfc.section.2. 6.p.3">Note that cached responses that contain the "must-revalidate" and/or "s-maxage" response directives are not allowed to be1227 <h2 id="rfc.section.2.7"><a href="#rfc.section.2.7">2.7</a> <a id="caching.authenticated.responses" href="#caching.authenticated.responses">Shared Caching of Authenticated Responses</a></h2> 1228 <p id="rfc.section.2.7.p.1">A shared cache <em class="bcp14">MUST NOT</em> use a cached response to a request with an Authorization header field (<a href="p7-auth.html#header.authorization" title="Authorization">Section 4.1</a> of <a href="#Part7" id="rfc.xref.Part7.2"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>) to satisfy any subsequent request unless a cache directive that allows such responses to be stored is present in the response. 1229 </p> 1230 <p id="rfc.section.2.7.p.2">In this specification, the following Cache-Control response directives (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section 3.2.2</a>) have such an effect: must-revalidate, public, s-maxage. 1231 </p> 1232 <p id="rfc.section.2.7.p.3">Note that cached responses that contain the "must-revalidate" and/or "s-maxage" response directives are not allowed to be 1214 1233 served stale (<a href="#serving.stale.responses" title="Serving Stale Responses">Section 2.3.3</a>) by shared caches. In particular, a response with either "max-age=0, must-revalidate" or "s-maxage=0" cannot be used to satisfy 1215 1234 a subsequent request without revalidating it on the origin server. 1216 1235 </p> 1217 <h2 id="rfc.section.2. 7"><a href="#rfc.section.2.7">2.7</a> <a id="caching.negotiated.responses" href="#caching.negotiated.responses">Caching Negotiated Responses</a></h2>1218 <p id="rfc.section.2. 7.p.1">When a cache receives a request that can be satisfied by a stored response that has a Vary header field (<a href="#header.vary" id="rfc.xref.header.vary.1" title="Vary">Section 3.5</a>), it <em class="bcp14">MUST NOT</em> use that response unless all of the selecting header fields nominated by the Vary header field match in both the original1236 <h2 id="rfc.section.2.8"><a href="#rfc.section.2.8">2.8</a> <a id="caching.negotiated.responses" href="#caching.negotiated.responses">Caching Negotiated Responses</a></h2> 1237 <p id="rfc.section.2.8.p.1">When a cache receives a request that can be satisfied by a stored response that has a Vary header field (<a href="#header.vary" id="rfc.xref.header.vary.1" title="Vary">Section 3.5</a>), it <em class="bcp14">MUST NOT</em> use that response unless all of the selecting header fields nominated by the Vary header field match in both the original 1219 1238 request (i.e., that associated with the stored response), and the presented request. 1220 1239 </p> 1221 <p id="rfc.section.2. 7.p.2">The selecting header fields from two requests are defined to match if and only if those in the first request can be transformed1240 <p id="rfc.section.2.8.p.2">The selecting header fields from two requests are defined to match if and only if those in the first request can be transformed 1222 1241 to those in the second request by applying any of the following: 1223 1242 </p> … … 1230 1249 </li> 1231 1250 </ul> 1232 <p id="rfc.section.2. 7.p.3">If (after any normalization that might take place) a header field is absent from a request, it can only match another request1251 <p id="rfc.section.2.8.p.3">If (after any normalization that might take place) a header field is absent from a request, it can only match another request 1233 1252 if it is also absent there. 1234 1253 </p> 1235 <p id="rfc.section.2. 7.p.4">A Vary header field-value of "*" always fails to match, and subsequent requests to that resource can only be properly interpreted1254 <p id="rfc.section.2.8.p.4">A Vary header field-value of "*" always fails to match, and subsequent requests to that resource can only be properly interpreted 1236 1255 by the origin server. 1237 1256 </p> 1238 <p id="rfc.section.2. 7.p.5">The stored response with matching selecting header fields is known as the selected response.</p>1239 <p id="rfc.section.2. 7.p.6">If multiple selected responses are available, the most recent response (as determined by the Date header field) is used; see <a href="#constructing.responses.from.caches" title="Constructing Responses from Caches">Section 2.2</a>.1240 </p> 1241 <p id="rfc.section.2. 7.p.7">If no selected response is available, the cache can forward the presented request to the origin server in a conditional request;1257 <p id="rfc.section.2.8.p.5">The stored response with matching selecting header fields is known as the selected response.</p> 1258 <p id="rfc.section.2.8.p.6">If multiple selected responses are available, the most recent response (as determined by the Date header field) is used; see <a href="#constructing.responses.from.caches" title="Constructing Responses from Caches">Section 2.2</a>. 1259 </p> 1260 <p id="rfc.section.2.8.p.7">If no selected response is available, the cache can forward the presented request to the origin server in a conditional request; 1242 1261 see <a href="#validation.model" title="Validation Model">Section 2.4</a>. 1243 1262 </p> 1244 <h2 id="rfc.section.2. 8"><a href="#rfc.section.2.8">2.8</a> <a id="combining.responses" href="#combining.responses">Combining Partial Content</a></h2>1245 <p id="rfc.section.2. 8.p.1">A response might transfer only a partial representation if the connection closed prematurely or if the request used one or1263 <h2 id="rfc.section.2.9"><a href="#rfc.section.2.9">2.9</a> <a id="combining.responses" href="#combining.responses">Combining Partial Content</a></h2> 1264 <p id="rfc.section.2.9.p.1">A response might transfer only a partial representation if the connection closed prematurely or if the request used one or 1246 1265 more Range specifiers (<a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>). After several such transfers, a cache might have received several ranges of the same representation. A cache <em class="bcp14">MAY</em> combine these ranges into a single stored response, and reuse that response to satisfy later requests, if they all share the 1247 1266 same strong validator and the cache complies with the client requirements in <a href="p5-range.html#combining.byte.ranges" title="Combining Ranges">Section 4.2</a> of <a href="#Part5" id="rfc.xref.Part5.3"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>. 1248 1267 </p> 1249 <p id="rfc.section.2. 8.p.2">When combining the new response with one or more stored responses, a cache <em class="bcp14">MUST</em>:1250 </p> 1251 <ul> 1252 <li>delete any Warning header fields in the stored response with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning. 3" title="Warning">Section 3.6</a>);1268 <p id="rfc.section.2.9.p.2">When combining the new response with one or more stored responses, a cache <em class="bcp14">MUST</em>: 1269 </p> 1270 <ul> 1271 <li>delete any Warning header fields in the stored response with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.4" title="Warning">Section 3.6</a>); 1253 1272 </li> 1254 1273 <li>retain any Warning header fields in the stored response with warn-code 2xx; and,</li> … … 1377 1396 </p> 1378 1397 <ul class="empty"> 1379 <li>The public response directive indicates that a response whose associated request contains an 'Authentication' header <em class="bcp14">MAY</em> be stored (see <a href="#caching.authenticated.responses" title="Shared Caching of Authenticated Responses">Section 2. 6</a>).1398 <li>The public response directive indicates that a response whose associated request contains an 'Authentication' header <em class="bcp14">MAY</em> be stored (see <a href="#caching.authenticated.responses" title="Shared Caching of Authenticated Responses">Section 2.7</a>). 1380 1399 </li> 1381 1400 </ul> … … 1558 1577 <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a> <a id="header.vary" href="#header.vary">Vary</a></h2> 1559 1578 <p id="rfc.section.3.5.p.1">The "Vary" header field conveys the set of header fields that were used to select the representation.</p> 1560 <p id="rfc.section.3.5.p.2">Caches use this information, in part, to determine whether a stored response can be used to satisfy a given request; see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section 2. 7</a>. determines, while the response is fresh, whether a cache is permitted to use the response to reply to a subsequent request1561 without validation; see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section 2. 7</a>.1579 <p id="rfc.section.3.5.p.2">Caches use this information, in part, to determine whether a stored response can be used to satisfy a given request; see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section 2.8</a>. determines, while the response is fresh, whether a cache is permitted to use the response to reply to a subsequent request 1580 without validation; see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section 2.8</a>. 1562 1581 </p> 1563 1582 <p id="rfc.section.3.5.p.3">In uncacheable or stale responses, the Vary field value advises the user agent about the criteria that were used to select … … 1895 1914 <td class="left">http</td> 1896 1915 <td class="left">standard</td> 1897 <td class="left"> <a href="#header.warning" id="rfc.xref.header.warning. 4" title="Warning">Section 3.6</a>1916 <td class="left"> <a href="#header.warning" id="rfc.xref.header.warning.5" title="Warning">Section 3.6</a> 1898 1917 </td> 1899 1918 </tr> … … 2008 2027 use. (<a href="#validation.model" title="Validation Model">Section 2.4</a>) 2009 2028 </p> 2010 <p id="rfc.section.A.p.3">Clarify denial of service attack avoidance requirement. (<a href="#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section 2. 5</a>)2029 <p id="rfc.section.A.p.3">Clarify denial of service attack avoidance requirement. (<a href="#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section 2.6</a>) 2011 2030 </p> 2012 2031 <p id="rfc.section.A.p.4">Change ABNF productions for header fields to only define the field value. (<a href="#header.field.definitions" title="Header Field Definitions">Section 3</a>) 2013 2032 </p> 2014 2033 <p id="rfc.section.A.p.5">Do not mention RFC 2047 encoding and multiple languages in Warning header fields anymore, as these aspects never were implemented. 2015 (<a href="#header.warning" id="rfc.xref.header.warning. 5" title="Warning">Section 3.6</a>)2034 (<a href="#header.warning" id="rfc.xref.header.warning.6" title="Warning">Section 3.6</a>) 2016 2035 </p> 2017 2036 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> … … 2386 2405 <li>Expires <a href="#rfc.xref.header.expires.1">2.1</a>, <a href="#rfc.xref.header.expires.2">2.3</a>, <a href="#rfc.xref.header.expires.3">2.3.1</a>, <a href="#rfc.iref.h.4"><b>3.3</b></a>, <a href="#rfc.xref.header.expires.4">5.3</a></li> 2387 2406 <li>Pragma <a href="#rfc.xref.header.pragma.1">2.2</a>, <a href="#rfc.xref.header.pragma.2">3.2</a>, <a href="#rfc.iref.h.5"><b>3.4</b></a>, <a href="#rfc.xref.header.pragma.3">5.3</a></li> 2388 <li>Vary <a href="#rfc.xref.header.vary.1">2. 7</a>, <a href="#rfc.iref.h.6"><b>3.5</b></a>, <a href="#rfc.xref.header.vary.2">5.3</a></li>2389 <li>Warning <a href="#rfc.xref.header.warning.1">2.3.3</a>, <a href="#rfc.xref.header.warning.2">2.4.1</a>, <a href="#rfc.xref.header.warning.3">2. 8</a>, <a href="#rfc.iref.h.7"><b>3.6</b></a>, <a href="#rfc.xref.header.warning.4">5.3</a>, <a href="#rfc.xref.header.warning.5">A</a></li>2407 <li>Vary <a href="#rfc.xref.header.vary.1">2.8</a>, <a href="#rfc.iref.h.6"><b>3.5</b></a>, <a href="#rfc.xref.header.vary.2">5.3</a></li> 2408 <li>Warning <a href="#rfc.xref.header.warning.1">2.3.3</a>, <a href="#rfc.xref.header.warning.2">2.4.1</a>, <a href="#rfc.xref.header.warning.3">2.5</a>, <a href="#rfc.xref.header.warning.4">2.9</a>, <a href="#rfc.iref.h.7"><b>3.6</b></a>, <a href="#rfc.xref.header.warning.5">5.3</a>, <a href="#rfc.xref.header.warning.6">A</a></li> 2390 2409 </ul> 2391 2410 </li> … … 2443 2462 </li> 2444 2463 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 2445 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1.3</a>, <a href="#rfc.xref.Part1.2">1.4</a>, <a href="#rfc.xref.Part1.3">1.4.1</a>, <a href="#rfc.xref.Part1.4">1.4.1</a>, <a href="#rfc.xref.Part1.5">1.4.1</a>, <a href="#rfc.xref.Part1.6">1.4.1</a>, <a href="#rfc.xref.Part1.7">1.4.2</a>, <a href="#rfc.xref.Part1.8">1.4.2</a>, <a href="#rfc.xref.Part1.9">1.4.2</a>, <a href="#rfc.xref.Part1.10">1.4.2</a>, <a href="#rfc.xref.Part1.11">2.1</a>, <a href="#rfc.xref.Part1.12">2.2</a>, <a href="#rfc.xref.Part1.13">2. 5</a>, <a href="#rfc.xref.Part1.14">2.5</a>, <a href="#rfc.xref.Part1.15">2.5</a>, <a href="#rfc.xref.Part1.16">2.7</a>, <a href="#rfc.xref.Part1.17">7</a>, <a href="#Part1"><b>8.1</b></a><ul>2464 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1.3</a>, <a href="#rfc.xref.Part1.2">1.4</a>, <a href="#rfc.xref.Part1.3">1.4.1</a>, <a href="#rfc.xref.Part1.4">1.4.1</a>, <a href="#rfc.xref.Part1.5">1.4.1</a>, <a href="#rfc.xref.Part1.6">1.4.1</a>, <a href="#rfc.xref.Part1.7">1.4.2</a>, <a href="#rfc.xref.Part1.8">1.4.2</a>, <a href="#rfc.xref.Part1.9">1.4.2</a>, <a href="#rfc.xref.Part1.10">1.4.2</a>, <a href="#rfc.xref.Part1.11">2.1</a>, <a href="#rfc.xref.Part1.12">2.2</a>, <a href="#rfc.xref.Part1.13">2.6</a>, <a href="#rfc.xref.Part1.14">2.6</a>, <a href="#rfc.xref.Part1.15">2.6</a>, <a href="#rfc.xref.Part1.16">2.8</a>, <a href="#rfc.xref.Part1.17">7</a>, <a href="#Part1"><b>8.1</b></a><ul> 2446 2465 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.2">1.4</a></li> 2447 2466 <li><em>Section 2</em> <a href="#rfc.xref.Part1.1">1.3</a></li> 2448 2467 <li><em>Section 2.7</em> <a href="#rfc.xref.Part1.8">1.4.2</a>, <a href="#rfc.xref.Part1.10">1.4.2</a></li> 2449 2468 <li><em>Section 3.2.1</em> <a href="#rfc.xref.Part1.4">1.4.1</a></li> 2450 <li><em>Section 3.2</em> <a href="#rfc.xref.Part1.7">1.4.2</a>, <a href="#rfc.xref.Part1.16">2. 7</a></li>2469 <li><em>Section 3.2</em> <a href="#rfc.xref.Part1.7">1.4.2</a>, <a href="#rfc.xref.Part1.16">2.8</a></li> 2451 2470 <li><em>Section 3.2.4</em> <a href="#rfc.xref.Part1.5">1.4.1</a>, <a href="#rfc.xref.Part1.6">1.4.1</a></li> 2452 <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.12">2.2</a>, <a href="#rfc.xref.Part1.13">2. 5</a>, <a href="#rfc.xref.Part1.14">2.5</a>, <a href="#rfc.xref.Part1.15">2.5</a></li>2471 <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.12">2.2</a>, <a href="#rfc.xref.Part1.13">2.6</a>, <a href="#rfc.xref.Part1.14">2.6</a>, <a href="#rfc.xref.Part1.15">2.6</a></li> 2453 2472 <li><em>Section 8.4</em> <a href="#rfc.xref.Part1.9">1.4.2</a></li> 2454 2473 <li><em>Section 11</em> <a href="#rfc.xref.Part1.17">7</a></li> 2455 2474 </ul> 2456 2475 </li> 2457 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">1.4.2</a>, <a href="#rfc.xref.Part2.2">2</a>, <a href="#rfc.xref.Part2.3">2.2</a>, <a href="#rfc.xref.Part2.4">2.3.1.1</a>, <a href="#rfc.xref.Part2.5">2.3.2</a>, <a href="#rfc.xref.Part2.6">2. 5</a>, <a href="#rfc.xref.Part2.7">3.3</a>, <a href="#Part2"><b>8.1</b></a><ul>2458 <li><em>Section 6.1.1</em> <a href="#rfc.xref.Part2.3">2.2</a>, <a href="#rfc.xref.Part2.6">2. 5</a></li>2476 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">1.4.2</a>, <a href="#rfc.xref.Part2.2">2</a>, <a href="#rfc.xref.Part2.3">2.2</a>, <a href="#rfc.xref.Part2.4">2.3.1.1</a>, <a href="#rfc.xref.Part2.5">2.3.2</a>, <a href="#rfc.xref.Part2.6">2.6</a>, <a href="#rfc.xref.Part2.7">3.3</a>, <a href="#Part2"><b>8.1</b></a><ul> 2477 <li><em>Section 6.1.1</em> <a href="#rfc.xref.Part2.3">2.2</a>, <a href="#rfc.xref.Part2.6">2.6</a></li> 2459 2478 <li><em>Section 7</em> <a href="#rfc.xref.Part2.4">2.3.1.1</a></li> 2460 2479 <li><em>Section 8</em> <a href="#rfc.xref.Part2.1">1.4.2</a>, <a href="#rfc.xref.Part2.7">3.3</a></li> … … 2469 2488 </ul> 2470 2489 </li> 2471 <li><em>Part5</em> <a href="#rfc.xref.Part5.1">2.1</a>, <a href="#rfc.xref.Part5.2">2. 8</a>, <a href="#rfc.xref.Part5.3">2.8</a>, <a href="#Part5"><b>8.1</b></a><ul>2472 <li><em>Section 4.2</em> <a href="#rfc.xref.Part5.3">2. 8</a></li>2490 <li><em>Part5</em> <a href="#rfc.xref.Part5.1">2.1</a>, <a href="#rfc.xref.Part5.2">2.9</a>, <a href="#rfc.xref.Part5.3">2.9</a>, <a href="#Part5"><b>8.1</b></a><ul> 2491 <li><em>Section 4.2</em> <a href="#rfc.xref.Part5.3">2.9</a></li> 2473 2492 </ul> 2474 2493 </li> 2475 <li><em>Part7</em> <a href="#rfc.xref.Part7.1">2.1</a>, <a href="#rfc.xref.Part7.2">2. 6</a>, <a href="#Part7"><b>8.1</b></a><ul>2476 <li><em>Section 4.1</em> <a href="#rfc.xref.Part7.1">2.1</a>, <a href="#rfc.xref.Part7.2">2. 6</a></li>2494 <li><em>Part7</em> <a href="#rfc.xref.Part7.1">2.1</a>, <a href="#rfc.xref.Part7.2">2.7</a>, <a href="#Part7"><b>8.1</b></a><ul> 2495 <li><em>Section 4.1</em> <a href="#rfc.xref.Part7.1">2.1</a>, <a href="#rfc.xref.Part7.2">2.7</a></li> 2477 2496 </ul> 2478 2497 </li> … … 2535 2554 </ul> 2536 2555 </li> 2537 <li>Vary header field <a href="#rfc.xref.header.vary.1">2. 7</a>, <a href="#rfc.iref.v.3"><b>3.5</b></a>, <a href="#rfc.xref.header.vary.2">5.3</a></li>2556 <li>Vary header field <a href="#rfc.xref.header.vary.1">2.8</a>, <a href="#rfc.iref.v.3"><b>3.5</b></a>, <a href="#rfc.xref.header.vary.2">5.3</a></li> 2538 2557 </ul> 2539 2558 </li> … … 2550 2569 </ul> 2551 2570 </li> 2552 <li>Warning header field <a href="#rfc.xref.header.warning.1">2.3.3</a>, <a href="#rfc.xref.header.warning.2">2.4.1</a>, <a href="#rfc.xref.header.warning.3">2. 8</a>, <a href="#rfc.iref.w.1"><b>3.6</b></a>, <a href="#rfc.xref.header.warning.4">5.3</a>, <a href="#rfc.xref.header.warning.5">A</a></li>2571 <li>Warning header field <a href="#rfc.xref.header.warning.1">2.3.3</a>, <a href="#rfc.xref.header.warning.2">2.4.1</a>, <a href="#rfc.xref.header.warning.3">2.5</a>, <a href="#rfc.xref.header.warning.4">2.9</a>, <a href="#rfc.iref.w.1"><b>3.6</b></a>, <a href="#rfc.xref.header.warning.5">5.3</a>, <a href="#rfc.xref.header.warning.6">A</a></li> 2553 2572 </ul> 2554 2573 </li>
Note: See TracChangeset
for help on using the changeset viewer.