Ignore:
Timestamp:
Mar 2, 2012, 4:16:57 PM (7 years ago)
Author:
mnot@…
Message:

Move cache-specific HEAD language to p6; fully specify effects on cache. Addresses #227.

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p6-cache.html

    r1552 r1554  
    463463  }
    464464  @bottom-center {
    465        content: "Expires September 2012";
     465       content: "Expires September 4, 2012";
    466466  }
    467467  @bottom-right {
     
    498498      <link href="p5-range.html" rel="prev">
    499499      <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.9 from 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/">
    501501      <link rel="schema.dct" href="http://purl.org/dc/terms/">
    502502      <meta name="dct.creator" content="Fielding, R.">
     
    511511      <meta name="dct.creator" content="Reschke, J. F.">
    512512      <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">
    514514      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    515515      <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 &#34;HTTP/1.1&#34; 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.">
     
    537537            </tr>
    538538            <tr>
    539                <td class="left">Expires: September 2012</td>
     539               <td class="left">Expires: September 4, 2012</td>
    540540               <td class="right">J. Mogul</td>
    541541            </tr>
     
    602602            <tr>
    603603               <td class="left"></td>
    604                <td class="right">March 2012</td>
     604               <td class="right">March 3, 2012</td>
    605605            </tr>
    606606         </tbody>
     
    632632         in progress”.
    633633      </p>
    634       <p>This Internet-Draft will expire in September 2012.</p>
     634      <p>This Internet-Draft will expire on September 4, 2012.</p>
    635635      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    636636      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    675675               </li>
    676676               <li>2.4&nbsp;&nbsp;&nbsp;<a href="#validation.model">Validation Model</a><ul>
    677                      <li>2.4.1&nbsp;&nbsp;&nbsp;<a href="#freshening.responses">Freshening Responses</a></li>
     677                     <li>2.4.1&nbsp;&nbsp;&nbsp;<a href="#freshening.responses">Freshening Responses with 304 Not Modified</a></li>
    678678                  </ul>
    679679               </li>
    680                <li>2.5&nbsp;&nbsp;&nbsp;<a href="#invalidation.after.updates.or.deletions">Request Methods that Invalidate</a></li>
    681                <li>2.6&nbsp;&nbsp;&nbsp;<a href="#caching.authenticated.responses">Shared Caching of Authenticated Responses</a></li>
    682                <li>2.7&nbsp;&nbsp;&nbsp;<a href="#caching.negotiated.responses">Caching Negotiated Responses</a></li>
    683                <li>2.8&nbsp;&nbsp;&nbsp;<a href="#combining.responses">Combining Partial Content</a></li>
     680               <li>2.5&nbsp;&nbsp;&nbsp;<a href="#head.effects">Updating Caches with HEAD Responses</a></li>
     681               <li>2.6&nbsp;&nbsp;&nbsp;<a href="#invalidation.after.updates.or.deletions">Request Methods that Invalidate</a></li>
     682               <li>2.7&nbsp;&nbsp;&nbsp;<a href="#caching.authenticated.responses">Shared Caching of Authenticated Responses</a></li>
     683               <li>2.8&nbsp;&nbsp;&nbsp;<a href="#caching.negotiated.responses">Caching Negotiated Responses</a></li>
     684               <li>2.9&nbsp;&nbsp;&nbsp;<a href="#combining.responses">Combining Partial Content</a></li>
    684685            </ul>
    685686         </li>
     
    904905      </p>
    905906      <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&nbsp;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&nbsp;2.8</a>).
    907908      </p>
    908909      <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a id="response.cacheability" href="#response.cacheability">Response Cacheability</a></h2>
     
    916917         <li>the "private" cache response directive (see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;3.2.2</a>) does not appear in the response, if the cache is shared, and
    917918         </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&nbsp;2.6</a>), and
     919         <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&nbsp;2.7</a>), and
    919920         </li>
    920921         <li>the response either:
     
    945946         not understand the range units used in those fields.
    946947      </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&nbsp;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 specifies
     948      <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&nbsp;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
    948949         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.
    949950      </p>
     
    955956         </li>
    956957         <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&nbsp;2.7</a>), and
     958         <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&nbsp;2.8</a>), and
    958959         </li>
    959960         <li>the presented request does not contain the no-cache pragma (<a href="#header.pragma" id="rfc.xref.header.pragma.1" title="Pragma">Section&nbsp;3.4</a>), nor the no-cache cache directive (<a href="#cache-request-directive" title="Request Cache-Control Directives">Section&nbsp;3.2.1</a>), unless the stored response is successfully validated (<a href="#validation.model" title="Validation Model">Section&nbsp;2.4</a>), and
     
    979980         having received a corresponding response.
    980981      </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&nbsp;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&nbsp;2.6</a>.
    982983      </p>
    983984      <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:
     
    11361137      <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a>&nbsp;<a id="validation.model" href="#validation.model">Validation Model</a></h2>
    11371138      <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&nbsp;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 to
     1139         fresh, or one cannot be selected; see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;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
    11391140         update it. This process is known as "validating" or "revalidating" the stored response.
    11401141      </p>
    11411142      <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&nbsp;2.7</a>) stored response, if available.
     1143         header field from the selected (see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;2.8</a>) stored response, if available.
    11431144      </p>
    11441145      <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
     
    11501151      <p id="rfc.section.2.4.p.5"> </p>
    11511152      <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&nbsp;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&nbsp;2.4.1</a>.
    11531154         </li>
    11541155         <li>A full response (i.e., one with a response body) indicates that none of the stored responses nominated in the conditional
     
    11601161         </li>
    11611162      </ul>
    1162       <h3 id="rfc.section.2.4.1"><a href="#rfc.section.2.4.1">2.4.1</a>&nbsp;<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>&nbsp;<a id="freshening.responses" href="#freshening.responses">Freshening Responses with 304 Not Modified</a></h3>
    11631164      <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
    11641165         key, the cache needs to identify which of the stored responses are updated by this new response and then update the stored
     
    11871188         </li>
    11881189      </ul>
    1189       <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a>&nbsp;<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>&nbsp;<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&nbsp;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&nbsp;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&nbsp;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>&nbsp;<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
    11911210         to keep their contents up-to-date.
    11921211      </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 response
     1212      <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
    11941213         to a request with an unsafe method is received.
    11951214      </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 host
     1215      <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
    11971216         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.
    11981217      </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 all
     1218      <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
    12021221         stored responses related to the effective request URI, or will mark these as "invalid" and in need of a mandatory validation
    12031222         before they can be returned in response to a subsequent request.
    12041223      </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 the
     1224      <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
    12061225         change at the origin server might not have gone through the cache where a response is stored.
    12071226      </p>
    1208       <h2 id="rfc.section.2.6"><a href="#rfc.section.2.6">2.6</a>&nbsp;<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&nbsp;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 be
     1227      <h2 id="rfc.section.2.7"><a href="#rfc.section.2.7">2.7</a>&nbsp;<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&nbsp;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
    12141233         served stale (<a href="#serving.stale.responses" title="Serving Stale Responses">Section&nbsp;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
    12151234         a subsequent request without revalidating it on the origin server.
    12161235      </p>
    1217       <h2 id="rfc.section.2.7"><a href="#rfc.section.2.7">2.7</a>&nbsp;<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&nbsp;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
     1236      <h2 id="rfc.section.2.8"><a href="#rfc.section.2.8">2.8</a>&nbsp;<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&nbsp;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
    12191238         request (i.e., that associated with the stored response), and the presented request.
    12201239      </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 transformed
     1240      <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
    12221241         to those in the second request by applying any of the following:
    12231242      </p>
     
    12301249         </li>
    12311250      </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 request
     1251      <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
    12331252         if it is also absent there.
    12341253      </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 interpreted
     1254      <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
    12361255         by the origin server.
    12371256      </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&nbsp;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&nbsp;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;
    12421261         see <a href="#validation.model" title="Validation Model">Section&nbsp;2.4</a>.
    12431262      </p>
    1244       <h2 id="rfc.section.2.8"><a href="#rfc.section.2.8">2.8</a>&nbsp;<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 or
     1263      <h2 id="rfc.section.2.9"><a href="#rfc.section.2.9">2.9</a>&nbsp;<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
    12461265         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
    12471266         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>.
    12481267      </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&nbsp;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&nbsp;3.6</a>);
    12531272         </li>
    12541273         <li>retain any Warning header fields in the stored response with warn-code 2xx; and,</li>
     
    13771396      </p>
    13781397      <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&nbsp;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&nbsp;2.7</a>).
    13801399         </li>
    13811400      </ul>
     
    15581577      <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a>&nbsp;<a id="header.vary" href="#header.vary">Vary</a></h2>
    15591578      <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&nbsp;2.7</a>. determines, while the response is fresh, whether a cache is permitted to use the response to reply to a subsequent request
    1561          without validation; see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;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&nbsp;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&nbsp;2.8</a>.
    15621581      </p>
    15631582      <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
     
    18951914                  <td class="left">http</td>
    18961915                  <td class="left">standard</td>
    1897                   <td class="left"> <a href="#header.warning" id="rfc.xref.header.warning.4" title="Warning">Section&nbsp;3.6</a>
     1916                  <td class="left"> <a href="#header.warning" id="rfc.xref.header.warning.5" title="Warning">Section&nbsp;3.6</a>
    18981917                  </td>
    18991918               </tr>
     
    20082027         use. (<a href="#validation.model" title="Validation Model">Section&nbsp;2.4</a>)
    20092028      </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&nbsp;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&nbsp;2.6</a>)
    20112030      </p>
    20122031      <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&nbsp;3</a>)
    20132032      </p>
    20142033      <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&nbsp;3.6</a>)
     2034         (<a href="#header.warning" id="rfc.xref.header.warning.6" title="Warning">Section&nbsp;3.6</a>)
    20162035      </p>
    20172036      <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
     
    23862405                        <li>Expires&nbsp;&nbsp;<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>
    23872406                        <li>Pragma&nbsp;&nbsp;<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&nbsp;&nbsp;<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&nbsp;&nbsp;<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&nbsp;&nbsp;<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&nbsp;&nbsp;<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>
    23902409                     </ul>
    23912410                  </li>
     
    24432462            </li>
    24442463            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    2445                   <li><em>Part1</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>
    24462465                        <li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.2">1.4</a></li>
    24472466                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.3</a></li>
    24482467                        <li><em>Section 2.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.8">1.4.2</a>, <a href="#rfc.xref.Part1.10">1.4.2</a></li>
    24492468                        <li><em>Section 3.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.4">1.4.1</a></li>
    2450                         <li><em>Section 3.2</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part1.7">1.4.2</a>, <a href="#rfc.xref.Part1.16">2.8</a></li>
    24512470                        <li><em>Section 3.2.4</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>
    24532472                        <li><em>Section 8.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.9">1.4.2</a></li>
    24542473                        <li><em>Section 11</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.17">7</a></li>
    24552474                     </ul>
    24562475                  </li>
    2457                   <li><em>Part2</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">2.2</a>, <a href="#rfc.xref.Part2.6">2.5</a></li>
     2476                  <li><em>Part2</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">2.2</a>, <a href="#rfc.xref.Part2.6">2.6</a></li>
    24592478                        <li><em>Section 7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">2.3.1.1</a></li>
    24602479                        <li><em>Section 8</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1.4.2</a>, <a href="#rfc.xref.Part2.7">3.3</a></li>
     
    24692488                     </ul>
    24702489                  </li>
    2471                   <li><em>Part5</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part5.3">2.8</a></li>
     2490                  <li><em>Part5</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part5.3">2.9</a></li>
    24732492                     </ul>
    24742493                  </li>
    2475                   <li><em>Part7</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part7.1">2.1</a>, <a href="#rfc.xref.Part7.2">2.6</a></li>
     2494                  <li><em>Part7</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part7.1">2.1</a>, <a href="#rfc.xref.Part7.2">2.7</a></li>
    24772496                     </ul>
    24782497                  </li>
     
    25352554                     </ul>
    25362555                  </li>
    2537                   <li>Vary header field&nbsp;&nbsp;<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&nbsp;&nbsp;<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>
    25382557               </ul>
    25392558            </li>
     
    25502569                     </ul>
    25512570                  </li>
    2552                   <li>Warning header field&nbsp;&nbsp;<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&nbsp;&nbsp;<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>
    25532572               </ul>
    25542573            </li>
Note: See TracChangeset for help on using the changeset viewer.