Ignore:
Timestamp:
Sep 7, 2010, 4:46:12 AM (9 years ago)
Author:
julian.reschke@…
Message:

Uniform use of 'header field' (see #234)

File:
1 edited

Legend:

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

    r981 r994  
    402402      <meta name="dct.creator" content="Reschke, J. F.">
    403403      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest">
    404       <meta name="dct.issued" scheme="ISO8601" content="2010-09-01">
     404      <meta name="dct.issued" scheme="ISO8601" content="2010-09-07">
    405405      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    406406      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. 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.">
     
    428428            </tr>
    429429            <tr>
    430                <td class="left">Expires: March 5, 2011</td>
     430               <td class="left">Expires: March 11, 2011</td>
    431431               <td class="right">J. Mogul</td>
    432432            </tr>
     
    489489            <tr>
    490490               <td class="left"></td>
    491                <td class="right">September 1, 2010</td>
     491               <td class="right">September 7, 2010</td>
    492492            </tr>
    493493         </tbody>
     
    515515         in progress”.
    516516      </p>
    517       <p>This Internet-Draft will expire on March 5, 2011.</p>
     517      <p>This Internet-Draft will expire on March 11, 2011.</p>
    518518      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    519519      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    563563               <li class="tocline1">2.6&nbsp;&nbsp;&nbsp;<a href="#caching.authenticated.responses">Shared Caching of Authenticated Responses</a></li>
    564564               <li class="tocline1">2.7&nbsp;&nbsp;&nbsp;<a href="#caching.negotiated.responses">Caching Negotiated Responses</a></li>
    565                <li class="tocline1">2.8&nbsp;&nbsp;&nbsp;<a href="#combining.headers">Combining Responses</a></li>
     565               <li class="tocline1">2.8&nbsp;&nbsp;&nbsp;<a href="#combining.responses">Combining Responses</a></li>
    566566            </ul>
    567567         </li>
     
    724724         <li>The request method is understood by the cache and defined as being cacheable, and</li>
    725725         <li>the response status code is understood by the cache, and</li>
    726          <li>the "no-store" cache directive (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.1" title="Cache-Control">Section&nbsp;3.2</a>) does not appear in request or response headers, and
     726         <li>the "no-store" cache directive (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.1" title="Cache-Control">Section&nbsp;3.2</a>) does not appear in request or response header fields, and
    727727         </li>
    728728         <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
    729729         </li>
    730          <li>the "Authorization" header (see <a href="p7-auth.html#header.authorization" title="Authorization">Section 3.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
     730         <li>the "Authorization" header field (see <a href="p7-auth.html#header.authorization" title="Authorization">Section 3.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
    731731         </li>
    732732         <li>the response either:
    733733            <ul>
    734                <li>contains an Expires header (see <a href="#header.expires" id="rfc.xref.header.expires.1" title="Expires">Section&nbsp;3.3</a>), or
     734               <li>contains an Expires header field (see <a href="#header.expires" id="rfc.xref.header.expires.1" title="Expires">Section&nbsp;3.3</a>), or
    735735               </li>
    736736               <li>contains a max-age response cache directive (see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;3.2.2</a>), or
     
    752752      </p>
    753753      <h3 id="rfc.section.2.1.1"><a href="#rfc.section.2.1.1">2.1.1</a>&nbsp;<a id="errors.or.incomplete.response.cache.behavior" href="#errors.or.incomplete.response.cache.behavior">Storing Partial and Incomplete Responses</a></h3>
    754       <p id="rfc.section.2.1.1.p.1">A cache that receives an incomplete response (for example, with fewer bytes of data than specified in a Content-Length header)
    755          can store the response, but <em class="bcp14">MUST</em> treat it as a partial response <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>. Partial responses can be combined as described in <a href="p5-range.html#combining.byte.ranges" title="Combining Ranges">Section 4</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>; the result might be a full response or might still be partial. A cache <em class="bcp14">MUST NOT</em> return a partial response to a client without explicitly marking it as such using the 206 (Partial Content) status code.
    756       </p>
    757       <p id="rfc.section.2.1.1.p.2">A cache that does not support the Range and Content-Range headers <em class="bcp14">MUST NOT</em> store incomplete or partial responses.
     754      <p id="rfc.section.2.1.1.p.1">A cache that receives an incomplete response (for example, with fewer bytes of data than specified in a Content-Length header
     755         field) can store the response, but <em class="bcp14">MUST</em> treat it as a partial response <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>. Partial responses can be combined as described in <a href="p5-range.html#combining.byte.ranges" title="Combining Ranges">Section 4</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>; the result might be a full response or might still be partial. A cache <em class="bcp14">MUST NOT</em> return a partial response to a client without explicitly marking it as such using the 206 (Partial Content) status code.
     756      </p>
     757      <p id="rfc.section.2.1.1.p.2">A cache that does not support the Range and Content-Range header fields <em class="bcp14">MUST NOT</em> store incomplete or partial responses.
    758758      </p>
    759759      <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;<a id="constructing.responses.from.caches" href="#constructing.responses.from.caches">Constructing Responses from Caches</a></h2>
     
    764764         </li>
    765765         <li>the request method associated with the stored response allows it to be used for the presented request, and</li>
    766          <li>selecting request-headers 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
     766         <li>selecting request-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
    767767         </li>
    768768         <li>the presented request and stored response are free from directives that would prevent its use (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.2" title="Cache-Control">Section&nbsp;3.2</a> and <a href="#header.pragma" id="rfc.xref.header.pragma.1" title="Pragma">Section&nbsp;3.4</a>), and
     
    786786      <p id="rfc.section.2.2.p.4">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>.
    787787      </p>
    788       <p id="rfc.section.2.2.p.5">Caches <em class="bcp14">MUST</em> use the most recent response (as determined by the Date header) when more than one suitable response is stored. They can also
    789          forward a request with "Cache-Control: max-age=0" or "Cache-Control: no-cache" to disambiguate which response to use.
     788      <p id="rfc.section.2.2.p.5">Caches <em class="bcp14">MUST</em> use the most recent response (as determined by the Date header field) when more than one suitable response is stored. They
     789         can also forward a request with "Cache-Control: max-age=0" or "Cache-Control: no-cache" to disambiguate which response to
     790         use.
    790791      </p>
    791792      <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;<a id="expiration.model" href="#expiration.model">Freshness Model</a></h2>
     
    794795      </p>
    795796      <p id="rfc.section.2.3.p.2">The primary mechanism for determining freshness is for an origin server to provide an explicit expiration time in the future,
    796          using either the Expires header (<a href="#header.expires" id="rfc.xref.header.expires.2" title="Expires">Section&nbsp;3.3</a>) or the max-age response cache directive (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;3.2.2</a>). Generally, origin servers will assign future explicit expiration times to responses in the belief that the representation
     797         using either the Expires header field (<a href="#header.expires" id="rfc.xref.header.expires.2" title="Expires">Section&nbsp;3.3</a>) or the max-age response cache directive (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;3.2.2</a>). Generally, origin servers will assign future explicit expiration times to responses in the belief that the representation
    797798         is not likely to change in a semantically significant way before the expiration time is reached.
    798799      </p>
     
    801802         requests.
    802803      </p>
    803       <p id="rfc.section.2.3.p.4">Since origin servers do not always provide explicit expiration times, HTTP caches <em class="bcp14">MAY</em> assign heuristic expiration times when explicit times are not specified, employing algorithms that use other header values
     804      <p id="rfc.section.2.3.p.4">Since origin servers do not always provide explicit expiration times, HTTP caches <em class="bcp14">MAY</em> assign heuristic expiration times when explicit times are not specified, employing algorithms that use other heade field values
    804805         (such as the Last-Modified time) to estimate a plausible expiration time. The HTTP/1.1 specification does not provide specific
    805806         algorithms, but does impose worst-case constraints on their results.
     
    824825         <li>If the max-age response cache directive (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;3.2.2</a>) is present, use its value, or
    825826         </li>
    826          <li>If the Expires response header (<a href="#header.expires" id="rfc.xref.header.expires.3" title="Expires">Section&nbsp;3.3</a>) is present, use its value minus the value of the Date response header, or
     827         <li>If the Expires response header field (<a href="#header.expires" id="rfc.xref.header.expires.3" title="Expires">Section&nbsp;3.3</a>) is present, use its value minus the value of the Date response header field, or
    827828         </li>
    828829         <li>Otherwise, no explicit expiration time is present in the response. A heuristic freshness lifetime might be applicable; see <a href="#heuristic.freshness" title="Calculating Heuristic Freshness">Section&nbsp;2.3.1.1</a>.
     
    834835         to be used (including the following in <a href="p2-semantics.html#status.codes" title="Status Code Definitions">Section 8</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>: 200, 203, 206, 300, 301 and 410), a heuristic expiration time <em class="bcp14">MAY</em> be calculated. Heuristics <em class="bcp14">MUST NOT</em> be used for response status codes that do not explicitly allow it.
    835836      </p>
    836       <p id="rfc.section.2.3.1.1.p.2">When a heuristic is used to calculate freshness lifetime, the cache <em class="bcp14">SHOULD</em> attach a Warning header with a 113 warn-code to the response if its current_age is more than 24 hours and such a warning is
    837          not already present.
    838       </p>
    839       <p id="rfc.section.2.3.1.1.p.3">Also, if the response has a Last-Modified header (<a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 6.6</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>), the heuristic expiration value <em class="bcp14">SHOULD</em> be no more than some fraction of the interval since that time. A typical setting of this fraction might be 10%.
     837      <p id="rfc.section.2.3.1.1.p.2">When a heuristic is used to calculate freshness lifetime, the cache <em class="bcp14">SHOULD</em> attach a Warning header field with a 113 warn-code to the response if its current_age is more than 24 hours and such a warning
     838         is not already present.
     839      </p>
     840      <p id="rfc.section.2.3.1.1.p.3">Also, if the response has a Last-Modified header field (<a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 6.6</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>), the heuristic expiration value <em class="bcp14">SHOULD</em> be no more than some fraction of the interval since that time. A typical setting of this fraction might be 10%.
    840841      </p>
    841842      <div class="note" id="rfc.section.2.3.1.1.p.4">
     
    846847      </div>
    847848      <h3 id="rfc.section.2.3.2"><a href="#rfc.section.2.3.2">2.3.2</a>&nbsp;<a id="age.calculations" href="#age.calculations">Calculating Age</a></h3>
    848       <p id="rfc.section.2.3.2.p.1">HTTP/1.1 uses the Age response-header to convey the estimated age of the response message when obtained from a cache. The
    849          Age field value is the cache's estimate of the amount of time since the response was generated or validated by the origin
     849      <p id="rfc.section.2.3.2.p.1">HTTP/1.1 uses the Age response-header field to convey the estimated age of the response message when obtained from a cache.
     850         The Age field value is the cache's estimate of the amount of time since the response was generated or validated by the origin
    850851         server. In essence, the Age value is the sum of the time that the response has been resident in each of the caches along the
    851852         path from the origin server, plus the amount of time it has been in transit along network paths.
     
    855856      </p>
    856857      <ul class="empty">
    857          <li>The term "age_value" denotes the value of the Age header (<a href="#header.age" id="rfc.xref.header.age.2" title="Age">Section&nbsp;3.1</a>), in a form appropriate for arithmetic operation; or 0, if not available.
     858         <li>The term "age_value" denotes the value of the Age header field (<a href="#header.age" id="rfc.xref.header.age.2" title="Age">Section&nbsp;3.1</a>), in a form appropriate for arithmetic operation; or 0, if not available.
    858859         </li>
    859860      </ul>
     
    861862      </p>
    862863      <ul class="empty">
    863          <li>HTTP/1.1 requires origin servers to send a Date header, if possible, with every response, giving the time at which the response
    864             was generated. The term "date_value" denotes the value of the Date header, in a form appropriate for arithmetic operations.
    865             See <a href="p1-messaging.html#header.date" title="Date">Section 9.3</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> for the definition of the Date header, and for requirements regarding responses without a Date response header.
     864         <li>HTTP/1.1 requires origin servers to send a Date header field, if possible, with every response, giving the time at which the
     865            response was generated. The term "date_value" denotes the value of the Date header field, in a form appropriate for arithmetic
     866            operations. See <a href="p1-messaging.html#header.date" title="Date">Section 9.3</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> for the definition of the Date header field, and for requirements regarding responses without it.
    866867         </li>
    867868      </ul>
     
    913914         path) or otherwise explicitly allowed (e.g., the max-stale request directive; see <a href="#cache-request-directive" title="Request Cache-Control Directives">Section&nbsp;3.2.1</a>).
    914915      </p>
    915       <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&nbsp;3.6</a>). Likewise, the 112 warn-code <em class="bcp14">SHOULD</em> be sent on stale responses if the cache is disconnected.
     916      <p id="rfc.section.2.3.3.p.4">Stale responses <em class="bcp14">SHOULD</em> have a Warning header field with the 110 warn-code (see <a href="#header.warning" id="rfc.xref.header.warning.1" title="Warning">Section&nbsp;3.6</a>). Likewise, the 112 warn-code <em class="bcp14">SHOULD</em> be sent on stale responses if the cache is disconnected.
    916917      </p>
    917918      <p id="rfc.section.2.3.3.p.5">If a cache receives a first-hand response (either an entire response, or a 304 (Not Modified) response) that it would normally
    918          forward to the requesting client, and the received response is no longer fresh, the cache <em class="bcp14">SHOULD</em> forward it to the requesting client without adding a new Warning (but without removing any existing Warning headers). A cache <em class="bcp14">SHOULD NOT</em> attempt to validate a response simply because that response became stale in transit.
     919         forward to the requesting client, and the received response is no longer fresh, the cache <em class="bcp14">SHOULD</em> forward it to the requesting client without adding a new Warning (but without removing any existing Warning header fields).
     920         A cache <em class="bcp14">SHOULD NOT</em> attempt to validate a response simply because that response became stale in transit.
    919921      </p>
    920922      <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>
     
    923925         update it. This process is known as "validating" or "revalidating" the stored response.
    924926      </p>
    925       <p id="rfc.section.2.4.p.2">When sending such a conditional request, the cache <em class="bcp14">SHOULD</em> add an If-Modified-Since header whose value is that of the Last-Modified header from the selected (see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;2.7</a>) stored response, if available.
    926       </p>
    927       <p id="rfc.section.2.4.p.3">Additionally, the cache <em class="bcp14">SHOULD</em> add an If-None-Match header whose value is that of the ETag header(s) from all responses stored for the requested URI, if
    928          present. However, if any of the stored responses contains only partial content, its entity-tag <em class="bcp14">SHOULD NOT</em> be included in the If-None-Match header field unless the request is for a range that would be fully satisfied by that stored
     927      <p id="rfc.section.2.4.p.2">When sending such a conditional request, the cache <em class="bcp14">SHOULD</em> add an If-Modified-Since header field whose value is that of the Last-Modified header field from the selected (see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;2.7</a>) stored response, if available.
     928      </p>
     929      <p id="rfc.section.2.4.p.3">Additionally, the cache <em class="bcp14">SHOULD</em> add an If-None-Match header field whose value is that of the ETag header field(s) from all responses stored for the requested
     930         URI, if present. However, if any of the stored responses contains only partial content, its entity-tag <em class="bcp14">SHOULD NOT</em> be included in the If-None-Match header field unless the request is for a range that would be fully satisfied by that stored
    929931         response.
    930932      </p>
    931       <p id="rfc.section.2.4.p.4">A 304 (Not Modified) response status code indicates that the stored response can be updated and reused; see <a href="#combining.headers" title="Combining Responses">Section&nbsp;2.8</a>.
     933      <p id="rfc.section.2.4.p.4">A 304 (Not Modified) response status code indicates that the stored response can be updated and reused; see <a href="#combining.responses" title="Combining Responses">Section&nbsp;2.8</a>.
    932934      </p>
    933935      <p id="rfc.section.2.4.p.5">A full response (i.e., one with a response body) indicates that none of the stored responses nominated in the conditional
     
    939941      <p id="rfc.section.2.5.p.1">Because unsafe methods (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 7.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) have the potential for changing state on the origin server, intervening caches can use them to keep their contents up-to-date.
    940942      </p>
    941       <p id="rfc.section.2.5.p.2">The following HTTP methods <em class="bcp14">MUST</em> cause a cache to 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 headers (if present):
     943      <p id="rfc.section.2.5.p.2">The following HTTP methods <em class="bcp14">MUST</em> cause a cache to 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 header fields (if present):
    942944      </p>
    943945      <ul>
     
    946948         <li>POST</li>
    947949      </ul>
    948       <p id="rfc.section.2.5.p.3">An invalidation based on a URI from a Location or Content-Location header <em class="bcp14">MUST NOT</em> be performed if the host part of that URI differs from the host 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.
     950      <p id="rfc.section.2.5.p.3">An invalidation based on a URI from a Location or Content-Location header field <em class="bcp14">MUST NOT</em> be performed if the host part of that URI differs from the host 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.
    949951      </p>
    950952      <p id="rfc.section.2.5.p.4">A cache that passes through requests for methods it does not understand <em class="bcp14">SHOULD</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>).
     
    957959      </p>
    958960      <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>
    959       <p id="rfc.section.2.6.p.1">Shared caches <em class="bcp14">MUST NOT</em> use a cached response to a request with an Authorization header (<a href="p7-auth.html#header.authorization" title="Authorization">Section 3.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.
     961      <p id="rfc.section.2.6.p.1">Shared caches <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 3.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.
    960962      </p>
    961963      <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.
     
    966968      </p>
    967969      <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>
    968       <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 request-headers nominated by the Vary header match in both the original request
    969          (i.e., that associated with the stored response), and the presented request.
    970       </p>
    971       <p id="rfc.section.2.7.p.2">The selecting request-headers from two requests are defined to match if and only if those in the first request can be transformed
    972          to those in the second request by applying any of the following:
    973       </p>
    974       <ul>
    975          <li>adding or removing whitespace, where allowed in the header's syntax</li>
     970      <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 request-header fields nominated by the Vary header field match in both the original
     971         request (i.e., that associated with the stored response), and the presented request.
     972      </p>
     973      <p id="rfc.section.2.7.p.2">The selecting request-header fields from two requests are defined to match if and only if those in the first request can be
     974         transformed to those in the second request by applying any of the following:
     975      </p>
     976      <ul>
     977         <li>adding or removing whitespace, where allowed in the header field's syntax</li>
    976978         <li>combining multiple message-header fields with the same field name (see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>)
    977979         </li>
    978          <li>normalizing both header values in a way that is known to have identical semantics, according to the header's specification
     980         <li>normalizing both header field values in a way that is known to have identical semantics, according to the header field's specification
    979981            (e.g., re-ordering field values when order is not significant; case-normalization, where values are defined to be case-insensitive)
    980982         </li>
     
    986988         by the origin server.
    987989      </p>
    988       <p id="rfc.section.2.7.p.5">The stored response with matching selecting request-headers is known as the selected response.</p>
     990      <p id="rfc.section.2.7.p.5">The stored response with matching selecting request-header fields is known as the selected response.</p>
    989991      <p id="rfc.section.2.7.p.6">If no selected response is available, the cache <em class="bcp14">MAY</em> forward the presented request to the origin server in a conditional request; see <a href="#validation.model" title="Validation Model">Section&nbsp;2.4</a>.
    990992      </p>
    991       <h2 id="rfc.section.2.8"><a href="#rfc.section.2.8">2.8</a>&nbsp;<a id="combining.headers" href="#combining.headers">Combining Responses</a></h2>
     993      <h2 id="rfc.section.2.8"><a href="#rfc.section.2.8">2.8</a>&nbsp;<a id="combining.responses" href="#combining.responses">Combining Responses</a></h2>
    992994      <p id="rfc.section.2.8.p.1">When a cache receives a 304 (Not Modified) response or a 206 (Partial Content) response (in this section, the "new" response"),
    993995         it needs to created an updated response by combining the stored response with the new one, so that the updated response can
     
    9981000      <p id="rfc.section.2.8.p.3">If the new response's status code is 206 (partial content), both the stored and new responses <em class="bcp14">MUST</em> have validators, and those validators <em class="bcp14">MUST</em> match using the strong comparison function (see <a href="p4-conditional.html#weak.and.strong.validators" title="Weak and Strong Validators">Section 4</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>). Otherwise, the responses <em class="bcp14">MUST NOT</em> be combined.
    9991001      </p>
    1000       <p id="rfc.section.2.8.p.4">The stored response headers are used as those of the updated response, except that </p>
    1001       <ul>
    1002          <li>any stored Warning headers with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.2" title="Warning">Section&nbsp;3.6</a>) <em class="bcp14">MUST</em> be deleted.
    1003          </li>
    1004          <li>any stored Warning headers with warn-code 2xx <em class="bcp14">MUST</em> be retained.
    1005          </li>
    1006          <li>any other headers provided in the new response <em class="bcp14">MUST</em> replace all instances of the corresponding headers from the stored response.
    1007          </li>
    1008       </ul>
    1009       <p id="rfc.section.2.8.p.5">The updated response headers <em class="bcp14">MUST</em> be used to replace those of the stored response in cache (unless the stored response is removed from cache). In the case of
     1002      <p id="rfc.section.2.8.p.4">The stored response header fields are used as those of the updated response, except that </p>
     1003      <ul>
     1004         <li>any stored Warning header fields with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.2" title="Warning">Section&nbsp;3.6</a>) <em class="bcp14">MUST</em> be deleted.
     1005         </li>
     1006         <li>any stored Warning header fields with warn-code 2xx <em class="bcp14">MUST</em> be retained.
     1007         </li>
     1008         <li>any other header fields provided in the new response <em class="bcp14">MUST</em> replace all instances of the corresponding header fields from the stored response.
     1009         </li>
     1010      </ul>
     1011      <p id="rfc.section.2.8.p.5">The updated response header fields <em class="bcp14">MUST</em> be used to replace those of the stored response in cache (unless the stored response is removed from cache). In the case of
    10101012         a 206 response, the combined representation <em class="bcp14">MAY</em> be stored.
    10111013      </p>
     
    10251027      <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>
    10261028</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,
    1027          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.
     1029         it <em class="bcp14">MUST</em> transmit an Age header field 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.
    10281030      </p>
    10291031      <p id="rfc.section.3.1.p.6">The presence of an Age header field in a response implies that a response is not first-hand. However, the converse is not
     
    11071109      </p>
    11081110      <ul class="empty">
    1109          <li>The no-transform request directive indicates that an intermediate cache or proxy <em class="bcp14">MUST NOT</em> change the Content-Encoding, Content-Range or Content-Type request headers, nor the request representation.
     1111         <li>The no-transform request directive indicates that an intermediate cache or proxy <em class="bcp14">MUST NOT</em> change the Content-Encoding, Content-Range or Content-Type request header fields, nor the request representation.
    11101112         </li>
    11111113      </ul>
     
    11431145         </li>
    11441146         <li>If the private response directive specifies one or more field-names, this requirement is limited to the field-values associated
    1145             with the listed response headers. That is, the specified field-names(s) <em class="bcp14">MUST NOT</em> be stored by a shared cache, whereas the remainder of the response message <em class="bcp14">MAY</em> be.
     1147            with the listed response header fields. That is, the specified field-names(s) <em class="bcp14">MUST NOT</em> be stored by a shared cache, whereas the remainder of the response message <em class="bcp14">MAY</em> be.
    11461148         </li>
    11471149         <li> <b>Note:</b> This usage of the word private only controls where the response can be stored; it cannot ensure the privacy of the message
     
    11581160         </li>
    11591161         <li>If the no-cache response directive specifies one or more field-names, this requirement is limited to the field-values associated
    1160             with the listed response headers. That is, the specified field-name(s) <em class="bcp14">MUST NOT</em> be sent in the response to a subsequent request without successful validation on the origin server. This allows an origin
     1162            with the listed response header fields. That is, the specified field-name(s) <em class="bcp14">MUST NOT</em> be sent in the response to a subsequent request without successful validation on the origin server. This allows an origin
    11611163            server to prevent the re-use of certain header fields in a response, while still allowing caching of the rest of the response.
    11621164         </li>
     
    12051207      <ul class="empty">
    12061208         <li>The s-maxage response directive indicates that, in shared caches, the maximum age specified by this directive overrides the
    1207             maximum age specified by either the max-age directive or the Expires header. The s-maxage directive also implies the semantics
    1208             of the proxy-revalidate response directive.
     1209            maximum age specified by either the max-age directive or the Expires header field. The s-maxage directive also implies the
     1210            semantics of the proxy-revalidate response directive.
    12091211         </li>
    12101212      </ul>
     
    12121214      </p>
    12131215      <ul class="empty">
    1214          <li>The no-transform response directive indicates that an intermediate cache or proxy <em class="bcp14">MUST NOT</em> change the Content-Encoding, Content-Range or Content-Type response headers, nor the response representation.
     1216         <li>The no-transform response directive indicates that an intermediate cache or proxy <em class="bcp14">MUST NOT</em> change the Content-Encoding, Content-Range or Content-Type response header fields, nor the response representation.
    12151217         </li>
    12161218      </ul>
     
    13051307      <div id="rfc.figure.u.16"></div><pre class="inline"><span id="rfc.iref.g.15"></span><span id="rfc.iref.g.16"></span>  <a href="#header.vary" class="smpl">Vary</a>   = "Vary" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.vary" class="smpl">Vary-v</a>
    13061308  <a href="#header.vary" class="smpl">Vary-v</a> = "*" / 1#<a href="#abnf.dependencies" class="smpl">field-name</a>
    1307 </pre><p id="rfc.section.3.5.p.5">The set of header fields named by the Vary field value is known as the selecting request-headers.</p>
     1309</pre><p id="rfc.section.3.5.p.5">The set of header fields named by the Vary field value is known as the selecting request-header fields.</p>
    13081310      <p id="rfc.section.3.5.p.6">Servers <em class="bcp14">SHOULD</em> include a Vary header field with any cacheable response that is subject to server-driven negotiation. Doing so allows a cache
    13091311         to properly interpret future requests on that resource and informs the user agent about the presence of negotiation on that
     
    13111313         the user agent with useful information about the dimensions over which the response varies at the time of the response.
    13121314      </p>
    1313       <p id="rfc.section.3.5.p.7">A Vary field value of "*" signals that unspecified parameters not limited to the request-headers (e.g., the network address
    1314          of the client), play a role in the selection of the response representation; therefore, a cache cannot determine whether this
    1315          response is appropriate. The "*" value <em class="bcp14">MUST NOT</em> be generated by a proxy server.
     1315      <p id="rfc.section.3.5.p.7">A Vary field value of "*" signals that unspecified parameters not limited to the request-header fields (e.g., the network
     1316         address of the client), play a role in the selection of the response representation; therefore, a cache cannot determine whether
     1317         this response is appropriate. The "*" value <em class="bcp14">MUST NOT</em> be generated by a proxy server.
    13161318      </p>
    13171319      <p id="rfc.section.3.5.p.8">The field-names given are not limited to the set of standard request-header fields defined by this specification. Field names
     
    13281330         code, distinguishes these responses from true failures.
    13291331      </p>
    1330       <p id="rfc.section.3.6.p.3">Warning headers can in general be applied to any message, however some warn-codes are specific to caches and can only be applied
    1331          to response messages.
     1332      <p id="rfc.section.3.6.p.3">Warning header fields can in general be applied to any message, however some warn-codes are specific to caches and can only
     1333         be applied to response messages.
    13321334      </p>
    13331335      <div id="rfc.figure.u.17"></div><pre class="inline"><span id="rfc.iref.g.17"></span><span id="rfc.iref.g.18"></span><span id="rfc.iref.g.19"></span><span id="rfc.iref.g.20"></span><span id="rfc.iref.g.21"></span><span id="rfc.iref.g.22"></span><span id="rfc.iref.g.23"></span>  <a href="#header.warning" class="smpl">Warning</a>    = "Warning" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.warning" class="smpl">Warning-v</a>
     
    13401342  <a href="#header.warning" class="smpl">warn-agent</a> = ( <a href="#abnf.dependencies" class="smpl">uri-host</a> [ ":" <a href="#abnf.dependencies" class="smpl">port</a> ] ) / <a href="#abnf.dependencies" class="smpl">pseudonym</a>
    13411343                  ; the name or pseudonym of the server adding
    1342                   ; the Warning header, for use in debugging
     1344                  ; the Warning header field, for use in debugging
    13431345  <a href="#header.warning" class="smpl">warn-text</a>  = <a href="#core.rules" class="smpl">quoted-string</a>
    13441346  <a href="#header.warning" class="smpl">warn-date</a>  = <a href="#notation" class="smpl">DQUOTE</a> <a href="#abnf.dependencies" class="smpl">HTTP-date</a> <a href="#notation" class="smpl">DQUOTE</a>
     
    13481350      <p id="rfc.section.3.6.p.6">When this occurs, the user agent <em class="bcp14">SHOULD</em> inform the user of as many of them as possible, in the order that they appear in the response.
    13491351      </p>
    1350       <p id="rfc.section.3.6.p.7">Systems that generate multiple Warning headers <em class="bcp14">SHOULD</em> order them with this user agent behavior in mind. New Warning headers <em class="bcp14">SHOULD</em> be added after any existing Warning headers.
     1352      <p id="rfc.section.3.6.p.7">Systems that generate multiple Warning header fields <em class="bcp14">SHOULD</em> order them with this user agent behavior in mind. New Warning header fields <em class="bcp14">SHOULD</em> be added after any existing Warning headers fields.
    13511353      </p>
    13521354      <p id="rfc.section.3.6.p.8">Warnings are assigned three digit warn-codes. The first digit indicates whether the Warning is required to be deleted from
     
    13601362         </li>
    13611363      </ul>
    1362       <p id="rfc.section.3.6.p.9">If an implementation sends a message with one or more Warning headers to a receiver whose version is HTTP/1.0 or lower, then
    1363          the sender <em class="bcp14">MUST</em> include in each warning-value a warn-date that matches the Date header in the message.
     1364      <p id="rfc.section.3.6.p.9">If an implementation sends a message with one or more Warning header fields to a receiver whose version is HTTP/1.0 or lower,
     1365         then the sender <em class="bcp14">MUST</em> include in each warning-value a warn-date that matches the Date header field in the message.
    13641366      </p>
    13651367      <p id="rfc.section.3.6.p.10">If an implementation receives a message with a warning-value that includes a warn-date, and that warn-date is different from
    13661368         the Date value in the response, then that warning-value <em class="bcp14">MUST</em> be deleted from the message before storing, forwarding, or using it. (preventing the consequences of naive caching of Warning
    1367          header fields.) If all of the warning-values are deleted for this reason, the Warning header <em class="bcp14">MUST</em> be deleted as well.
     1369         header fields.) If all of the warning-values are deleted for this reason, the Warning header field <em class="bcp14">MUST</em> be deleted as well.
    13681370      </p>
    13691371      <p id="rfc.section.3.6.p.11">The following warn-codes are defined by this specification, each with a recommended warn-text in English, and a description
     
    16771679      <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>)
    16781680      </p>
    1679       <p id="rfc.section.A.p.4">Do not mention RFC 2047 encoding and multiple languages in Warning headers anymore, as these aspects never were implemented.
     1681      <p id="rfc.section.A.p.4">Do not mention RFC 2047 encoding and multiple languages in Warning header fields anymore, as these aspects never were implemented.
    16801682         (<a href="#header.warning" id="rfc.xref.header.warning.4" title="Warning">Section&nbsp;3.6</a>)
    16811683      </p>
     
    17961798      </ul>
    17971799      <h2 id="rfc.section.C.4"><a href="#rfc.section.C.4">C.4</a>&nbsp;<a id="changes.since.02" href="#changes.since.02">Since draft-ietf-httpbis-p6-cache-02</a></h2>
    1798       <p id="rfc.section.C.4.p.1">Ongoing work on IANA Message Header Registration (&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/40">http://tools.ietf.org/wg/httpbis/trac/ticket/40</a>&gt;):
    1799       </p>
    1800       <ul>
    1801          <li>Reference RFC 3984, and update header registrations for headers defined in this document.</li>
     1800      <p id="rfc.section.C.4.p.1">Ongoing work on IANA Message Header Field Registration (&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/40">http://tools.ietf.org/wg/httpbis/trac/ticket/40</a>&gt;):
     1801      </p>
     1802      <ul>
     1803         <li>Reference RFC 3984, and update header field registrations for header fields defined in this document.</li>
    18021804      </ul>
    18031805      <h2 id="rfc.section.C.5"><a href="#rfc.section.C.5">C.5</a>&nbsp;<a id="changes.since.03" href="#changes.since.03">Since draft-ietf-httpbis-p6-cache-03</a></h2>
     
    18131815         <li>Use "/" instead of "|" for alternatives.</li>
    18141816         <li>Introduce new ABNF rules for "bad" whitespace ("BWS"), optional whitespace ("OWS") and required whitespace ("RWS").</li>
    1815          <li>Rewrite ABNFs to spell out whitespace rules, factor out header value format definitions.</li>
     1817         <li>Rewrite ABNFs to spell out whitespace rules, factor out header field value format definitions.</li>
    18161818      </ul>
    18171819      <h2 id="rfc.section.C.7"><a href="#rfc.section.C.7">C.7</a>&nbsp;<a id="changes.since.05" href="#changes.since.05">Since draft-ietf-httpbis-p6-cache-05</a></h2>
     
    18411843      <p id="rfc.section.C.8.p.2">Affected issues: </p>
    18421844      <ul>
    1843          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/37">http://tools.ietf.org/wg/httpbis/trac/ticket/37</a>&gt;: Vary and non-existant headers
     1845         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/37">http://tools.ietf.org/wg/httpbis/trac/ticket/37</a>&gt;: WVary and non-existant headers"
    18441846         </li>
    18451847      </ul>
Note: See TracChangeset for help on using the changeset viewer.