Source: https://trac.ietf.org/trac/httpbis/browser/draft-ietf-httpbis/latest/p6-cache.html?rev=2383
Timestamp: 2020-06-03 01:42:37
Document Index: 336759633

Matched Legal Cases: ['art4', 'art4', 'art4', 'art4', 'art4', 'art4', 'art4', 'art4', 'art4', 'art4', 'art4', 'art4', 'art4', 'art4', 'art4', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art4', 'art4', 'art4', 'art2', 'art2', 'art2', 'art1', 'art1', 'art1', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art4', 'art4', 'art4', 'art4', 'art4', 'art4', 'art4', 'art4', 'art4', 'art4', 'art4', 'art4', 'art4', 'art4', 'art4', 'art4', 'art4']

source: draft-ietf-httpbis/latest/p6-cache.html @ 2383
Last change on this file since 2383 was 2383, checked in by julian.reschke@…, 7 years ago
update ABNF appendix (see [2382])
content: "Expires March 17, 2014";
<meta name="dct.issued" scheme="ISO8601" content="2013-09-13">
<td class="left">Expires: March 17, 2014</td>
<td class="right">September 13, 2013</td>
<p>The changes in this draft are summarized in <a href="#changes.since.23" title="Since draft-ietf-httpbis-p6-cache-23">Appendix&nbsp;D.5</a>.
<p>This Internet-Draft will expire on March 17, 2014.</p>
<li><a href="#rfc.section.5.5.1">5.5.1</a>&nbsp;&nbsp;&nbsp;<a href="#warn.110">110 Response is Stale</a></li>
<li><a href="#rfc.section.5.5.2">5.5.2</a>&nbsp;&nbsp;&nbsp;<a href="#warn.111">111 Revalidation Failed</a></li>
<li><a href="#rfc.section.5.5.3">5.5.3</a>&nbsp;&nbsp;&nbsp;<a href="#warn.112">112 Disconnected Operation</a></li>
<li><a href="#rfc.section.5.5.4">5.5.4</a>&nbsp;&nbsp;&nbsp;<a href="#warn.113">113 Heuristic Expiration</a></li>
<li><a href="#rfc.section.5.5.5">5.5.5</a>&nbsp;&nbsp;&nbsp;<a href="#warn.199">199 Miscellaneous Warning</a></li>
<li><a href="#rfc.section.5.5.6">5.5.6</a>&nbsp;&nbsp;&nbsp;<a href="#warn.214">214 Transformation Applied</a></li>
<li><a href="#rfc.section.5.5.7">5.5.7</a>&nbsp;&nbsp;&nbsp;<a href="#warn.299">299 Miscellaneous Persistent Warning</a></li>
<li><a href="#rfc.section.5.5.8">5.5.8</a>&nbsp;&nbsp;&nbsp;<a href="#warn.code.extensions">Warn Code Extensions</a></li>
<li><a href="#rfc.section.D.5">D.5</a>&nbsp;&nbsp;&nbsp;<a href="#changes.since.23">Since draft-ietf-httpbis-p6-cache-23</a></li>
<p id="rfc.section.4.2.4.p.4">A cache <em class="bcp14">SHOULD</em> append a <a href="#header.warning" class="smpl">Warning</a> header field with the 110 warn-code (see <a href="#header.warning" id="rfc.xref.header.warning.2" title="Warning">Section&nbsp;5.5</a>) to stale responses. Likewise, a cache <em class="bcp14">SHOULD</em> add the 112 warn-code to stale responses if the cache is disconnected.
<h3 id="rfc.section.4.3.1"><a href="#rfc.section.4.3.1">4.3.1</a>&nbsp;<a id="validation.sent" href="#validation.sent">Sending a Validation Request</a></h3>
<h3 id="rfc.section.4.3.2"><a href="#rfc.section.4.3.2">4.3.2</a>&nbsp;<a id="validation.received" href="#validation.received">Handling a Received Validation Request</a></h3>
<p id="rfc.section.4.3.2.p.1">Each client in the request chain may have its own cache, so it is common for a cache at an intermediary or origin server to
receive conditional requests from other (outbound) caches. Likewise, some user agents make use of conditional requests to
limit data transfers to recently modified representations or to complete the transfer of partially retrieved representations.
<p id="rfc.section.4.3.2.p.2">If the request semantics can be satisfied with a cached response and a recipient cache has at least one response stored for
this primary cache key, the cache <em class="bcp14">MUST</em> evaluate received precondition header fields as part of its selection process for determining a suitable response. A cache <em class="bcp14">MUST NOT</em> evaluate received precondition header fields in a request with semantics that cannot be satisfied with a cached response,
or for which the cache has no prior stored responses, since such preconditions are intended for some other (inbound) server.
as defined in <a href="p4-conditional.html#precedence" title="Precedence">Section 6</a> of <a href="#Part4" id="rfc.xref.Part4.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>.
<p id="rfc.section.4.3.2.p.4">A request containing an <a href="p4-conditional.html#header.if-match" class="smpl">If-Match</a> header field (<a href="p4-conditional.html#header.if-match" title="If-Match">Section 3.1</a> of <a href="#Part4" id="rfc.xref.Part4.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>) indicates that the client wants to receive an error response if the cache has a stored response that cannot be used to answer
this request. The cache <em class="bcp14">MUST</em> generate a <a href="p4-conditional.html#status.412" class="smpl">412 (Precondition Failed)</a> response if the field-value is "*" and no suitable response is stored, or if the field-value is a list of entity-tags and
none of them match the entity-tag of a suitable stored response. Otherwise, the cache <em class="bcp14">MUST</em> generate a <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> response that reuses the most recent of its matching stored responses to satisfy the request.
<p id="rfc.section.4.3.2.p.5">A request containing an <a href="p4-conditional.html#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> header field (<a href="p4-conditional.html#header.if-unmodified-since" title="If-Unmodified-Since">Section 3.4</a> of <a href="#Part4" id="rfc.xref.Part4.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>) indicates that the client wants to receive an error response if the cache has a stored response that cannot be used to answer
this request. The cache <em class="bcp14">MUST</em> generate a <a href="p4-conditional.html#status.412" class="smpl">412 (Precondition Failed)</a> response if one of the following is true: 1) a stored response has a <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> field-value that is more recent than the conditional timestamp; 2) no <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> field is present, but a stored response has a <a href="p2-semantics.html#header.date" class="smpl">Date</a> field-value that is more recent than the conditional timestamp; or, 3) neither <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> nor <a href="p2-semantics.html#header.date" class="smpl">Date</a> is present, but the cache recorded a stored response as having been received at a time more recent than the conditional timestamp.
Otherwise, the cache <em class="bcp14">MUST</em> generate a <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> response that reuses the most recent of its matching stored responses to satisfy the request.
<p id="rfc.section.4.3.2.p.6">A request containing an <a href="p4-conditional.html#header.if-none-match" class="smpl">If-None-Match</a> header field (<a href="p4-conditional.html#header.if-none-match" title="If-None-Match">Section 3.2</a> of <a href="#Part4" id="rfc.xref.Part4.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>) indicates that the client wants to validate one or more of its stored responses. If the field-value is "*" and any suitable
response is stored, or the field-value is a list of entity-tags and at least one of them match the entity-tag of a suitable
stored response, the cache <em class="bcp14">MUST</em> generate a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response using the most suitable of those matching responses as the selected representation. Otherwise, if the cache has one
or more suitable stored responses that do not match the condition, the cache <em class="bcp14">MUST</em> generate a <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> response that reuses the most suitable of those stored responses to satisfy the request. Finally, if the cache has no suitable
an <a href="p4-conditional.html#header.if-none-match" class="smpl">If-None-Match</a> header field containing that union when it forwards the request toward the origin server. However, if a stored responses contains
only partial content, the cache <em class="bcp14">MUST NOT</em> include its entity-tag in the union unless the request is for a range that would be fully satisfied by that stored response.
<p id="rfc.section.4.3.2.p.7">A request containing an <a href="p4-conditional.html#header.if-modified-since" class="smpl">If-Modified-Since</a> header field (<a href="p4-conditional.html#header.if-modified-since" title="If-Modified-Since">Section 3.3</a> of <a href="#Part4" id="rfc.xref.Part4.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>) indicates that the client wants to validate one or more of its stored responses by modification date if the stored responses
have no entity-tag or the recipient does not implement <a href="p4-conditional.html#header.if-none-match" class="smpl">If-None-Match</a>. The cache <em class="bcp14">MUST</em> generate a <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> response, reusing the most recent of its stored responses to satisfy the request, if one of the following is true: 1) a stored
response has a <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> field-value that is more recent than the conditional timestamp; 2) no <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> field is present, but a stored response has a <a href="p2-semantics.html#header.date" class="smpl">Date</a> field-value that is more recent than the conditional timestamp; or, 3) neither <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> nor <a href="p2-semantics.html#header.date" class="smpl">Date</a> is present, but the cache recorded a stored response as having been received at a time more recent than the conditional timestamp.
Otherwise, if the cache has one or more suitable stored responses, the cache <em class="bcp14">MUST</em> generate a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response using the most recent of its suitable stored responses as the selected representation. Finally, if the cache has
no suitable stored responses, the cache <em class="bcp14">SHOULD</em> forward the conditional request toward the origin server.
<p id="rfc.section.4.3.2.p.8">A cache that implements partial responses to range requests, as defined in <a href="#Part5" id="rfc.xref.Part5.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>, also needs to evaluate a received <a href="p5-range.html#header.if-range" class="smpl">If-Range</a> header field (<a href="p5-range.html#header.if-range" title="If-Range">Section 3.2</a> of <a href="#Part5" id="rfc.xref.Part5.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>) in respect to its selected stored response.
<h3 id="rfc.section.4.3.3"><a href="#rfc.section.4.3.3">4.3.3</a>&nbsp;<a id="validation.response" href="#validation.response">Handling a Validation Response</a></h3>
<h3 id="rfc.section.4.3.4"><a href="#rfc.section.4.3.4">4.3.4</a>&nbsp;<a id="freshening.responses" href="#freshening.responses">Freshening Stored Responses upon Validation</a></h3>
<li>If the new response contains a <dfn>strong validator</dfn> (see <a href="p4-conditional.html#weak.and.strong.validators" title="Weak versus Strong">Section 2.1</a> of <a href="#Part4" id="rfc.xref.Part4.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>), then that strong validator identifies the selected representation for update. All of the stored responses with the same
<h3 id="rfc.section.4.3.5"><a href="#rfc.section.4.3.5">4.3.5</a>&nbsp;<a id="head.effects" href="#head.effects">Freshening Responses via HEAD</a></h3>
<li>delete any <a href="#header.warning" class="smpl">Warning</a> 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;5.5</a>);
<h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a>&nbsp;<a id="invalidation" href="#invalidation">Invalidation</a></h2>
<p id="rfc.section.4.4.p.1">Because unsafe request methods (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 4.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) such as PUT, POST or DELETE have the potential for changing state on the origin server, intervening caches can use them
<p id="rfc.section.4.4.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 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) as well as the URI(s) in the <a href="p2-semantics.html#header.location" class="smpl">Location</a> and <a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> response header fields (if present) when a non-error response to a request with an unsafe method is received.
<h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a>&nbsp;<a id="header.age" href="#header.age">Age</a></h2>
</pre><p id="rfc.section.5.1.p.3">Age field-values are non-negative integers, representing time in seconds (see <a href="#delta-seconds" title="Delta Seconds">Section&nbsp;1.2.1</a>).
<p id="rfc.section.5.1.p.4">The presence of an Age header field in a response implies that a response is not first-hand. However, the converse is not
<h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a>&nbsp;<a id="header.cache-control" href="#header.cache-control">Cache-Control</a></h2>
<h3 id="rfc.section.5.2.1"><a href="#rfc.section.5.2.1">5.2.1</a>&nbsp;<a id="cache-request-directive" href="#cache-request-directive">Request Cache-Control Directives</a></h3>
<h4 id="rfc.section.5.2.1.1"><a href="#rfc.section.5.2.1.1">5.2.1.1</a>&nbsp;<a id="cache-request-directive.max-age" href="#cache-request-directive.max-age">max-age</a></h4>
<p id="rfc.section.5.2.1.1.p.3"><b>Note:</b> This directive uses the token form of the argument syntax; e.g., 'max-age=5', not 'max-age="5"'. Senders <em class="bcp14">SHOULD NOT</em> use the quoted-string form.
<h4 id="rfc.section.5.2.1.2"><a href="#rfc.section.5.2.1.2">5.2.1.2</a>&nbsp;<a id="cache-request-directive.max-stale" href="#cache-request-directive.max-stale">max-stale</a></h4>
<p id="rfc.section.5.2.1.2.p.3"><b>Note:</b> This directive uses the token form of the argument syntax; e.g., 'max-stale=10', not 'max-stale="10"'. Senders <em class="bcp14">SHOULD NOT</em> use the quoted-string form.
<h4 id="rfc.section.5.2.1.3"><a href="#rfc.section.5.2.1.3">5.2.1.3</a>&nbsp;<a id="cache-request-directive.min-fresh" href="#cache-request-directive.min-fresh">min-fresh</a></h4>
<p id="rfc.section.5.2.1.3.p.3"><b>Note:</b> This directive uses the token form of the argument syntax; e.g., 'min-fresh=20', not 'min-fresh="20"'. Senders <em class="bcp14">SHOULD NOT</em> use the quoted-string form.
<h4 id="rfc.section.5.2.1.4"><a href="#rfc.section.5.2.1.4">5.2.1.4</a>&nbsp;<a id="cache-request-directive.no-cache" href="#cache-request-directive.no-cache">no-cache</a></h4>
<h4 id="rfc.section.5.2.1.5"><a href="#rfc.section.5.2.1.5">5.2.1.5</a>&nbsp;<a id="cache-request-directive.no-store" href="#cache-request-directive.no-store">no-store</a></h4>
<h4 id="rfc.section.5.2.1.6"><a href="#rfc.section.5.2.1.6">5.2.1.6</a>&nbsp;<a id="cache-request-directive.no-transform" href="#cache-request-directive.no-transform">no-transform</a></h4>
<h4 id="rfc.section.5.2.1.7"><a href="#rfc.section.5.2.1.7">5.2.1.7</a>&nbsp;<a id="cache-request-directive.only-if-cached" href="#cache-request-directive.only-if-cached">only-if-cached</a></h4>
<h3 id="rfc.section.5.2.2"><a href="#rfc.section.5.2.2">5.2.2</a>&nbsp;<a id="cache-response-directive" href="#cache-response-directive">Response Cache-Control Directives</a></h3>
<h4 id="rfc.section.5.2.2.1"><a href="#rfc.section.5.2.2.1">5.2.2.1</a>&nbsp;<a id="cache-response-directive.must-revalidate" href="#cache-response-directive.must-revalidate">must-revalidate</a></h4>
<h4 id="rfc.section.5.2.2.2"><a href="#rfc.section.5.2.2.2">5.2.2.2</a>&nbsp;<a id="cache-response-directive.no-cache" href="#cache-response-directive.no-cache">no-cache</a></h4>
<p id="rfc.section.5.2.2.2.p.5"><b>Note:</b> Although it has been back-ported to many implementations, some HTTP/1.0 caches will not recognize or obey this directive.
<p id="rfc.section.5.2.2.2.p.6"><b>Note:</b> This directive uses the quoted-string form of the argument syntax. Senders <em class="bcp14">SHOULD NOT</em> use the token form (even if quoting appears not to be needed for single-entry lists).
<h4 id="rfc.section.5.2.2.3"><a href="#rfc.section.5.2.2.3">5.2.2.3</a>&nbsp;<a id="cache-response-directive.no-store" href="#cache-response-directive.no-store">no-store</a></h4>
<h4 id="rfc.section.5.2.2.4"><a href="#rfc.section.5.2.2.4">5.2.2.4</a>&nbsp;<a id="cache-response-directive.no-transform" href="#cache-response-directive.no-transform">no-transform</a></h4>
<h4 id="rfc.section.5.2.2.5"><a href="#rfc.section.5.2.2.5">5.2.2.5</a>&nbsp;<a id="cache-response-directive.public" href="#cache-response-directive.public">public</a></h4>
<p id="rfc.section.5.2.2.5.p.1">The "public" response directive indicates that any cache <em class="bcp14">MAY</em> store the response, even if the response would normally be non-cacheable or cacheable only within a non-shared cache. (See <a href="#caching.authenticated.responses" title="Storing Responses to Authenticated Requests">Section&nbsp;3.2</a> for additional details related to the use of public in response to a request containing <a href="p7-auth.html#header.authorization" class="smpl">Authorization</a>, and <a href="#response.cacheability" title="Storing Responses in Caches">Section&nbsp;3</a> for details of how public affects responses that would normally not be stored, due to their status codes not being defined
<h4 id="rfc.section.5.2.2.6"><a href="#rfc.section.5.2.2.6">5.2.2.6</a>&nbsp;<a id="cache-response-directive.private" href="#cache-response-directive.private">private</a></h4>
<p id="rfc.section.5.2.2.6.p.5"><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
<p id="rfc.section.5.2.2.6.p.6"><b>Note:</b> This directive uses the quoted-string form of the argument syntax. Senders <em class="bcp14">SHOULD NOT</em> use the token form (even if quoting appears not to be needed for single-entry lists).
<h4 id="rfc.section.5.2.2.7"><a href="#rfc.section.5.2.2.7">5.2.2.7</a>&nbsp;<a id="cache-response-directive.proxy-revalidate" href="#cache-response-directive.proxy-revalidate">proxy-revalidate</a></h4>
<h4 id="rfc.section.5.2.2.8"><a href="#rfc.section.5.2.2.8">5.2.2.8</a>&nbsp;<a id="cache-response-directive.max-age" href="#cache-response-directive.max-age">max-age</a></h4>
<p id="rfc.section.5.2.2.8.p.3"><b>Note:</b> This directive uses the token form of the argument syntax; e.g., 'max-age=5', not 'max-age="5"'. Senders <em class="bcp14">SHOULD NOT</em> use the quoted-string form.
<h4 id="rfc.section.5.2.2.9"><a href="#rfc.section.5.2.2.9">5.2.2.9</a>&nbsp;<a id="cache-response-directive.s-maxage" href="#cache-response-directive.s-maxage">s-maxage</a></h4>
<p id="rfc.section.5.2.2.9.p.3"><b>Note:</b> This directive uses the token form of the argument syntax; e.g., 's-maxage=10', not 's-maxage="10"'. Senders <em class="bcp14">SHOULD NOT</em> use the quoted-string form.
<h3 id="rfc.section.5.2.3"><a href="#rfc.section.5.2.3">5.2.3</a>&nbsp;<a id="cache.control.extensions" href="#cache.control.extensions">Cache Control Extensions</a></h3>
<h2 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3</a>&nbsp;<a id="header.expires" href="#header.expires">Expires</a></h2>
<p id="rfc.section.5.3.p.3">The Expires value is an HTTP-date timestamp, as defined in <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 7.1.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>.
<h2 id="rfc.section.5.4"><a href="#rfc.section.5.4">5.4</a>&nbsp;<a id="header.pragma" href="#header.pragma">Pragma</a></h2>
<h2 id="rfc.section.5.5"><a href="#rfc.section.5.5">5.5</a>&nbsp;<a id="header.warning" href="#header.warning">Warning</a></h2>
</pre><p id="rfc.section.5.5.p.5">Multiple warnings can be attached to a response (either by the origin server or by a cache), including multiple warnings with
<p id="rfc.section.5.5.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.
<p id="rfc.section.5.5.p.7">Systems that generate multiple Warning header fields are encouraged to order them with this user agent behavior in mind. New
<p id="rfc.section.5.5.p.8">Warnings are assigned three digit warn-codes. The first digit indicates whether the Warning is required to be deleted from
<p id="rfc.section.5.5.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,
<p id="rfc.section.5.5.p.10">If a system receives a message with a warning-value that includes a warn-date, and that warn-date is different from the <a href="p2-semantics.html#header.date" class="smpl">Date</a> 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
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.
<h3 id="rfc.section.5.5.1"><a href="#rfc.section.5.5.1">5.5.1</a>&nbsp;<a id="warn.110" href="#warn.110">110 Response is Stale</a></h3>
<h3 id="rfc.section.5.5.2"><a href="#rfc.section.5.5.2">5.5.2</a>&nbsp;<a id="warn.111" href="#warn.111">111 Revalidation Failed</a></h3>
<h3 id="rfc.section.5.5.3"><a href="#rfc.section.5.5.3">5.5.3</a>&nbsp;<a id="warn.112" href="#warn.112">112 Disconnected Operation</a></h3>
<h3 id="rfc.section.5.5.4"><a href="#rfc.section.5.5.4">5.5.4</a>&nbsp;<a id="warn.113" href="#warn.113">113 Heuristic Expiration</a></h3>
<h3 id="rfc.section.5.5.5"><a href="#rfc.section.5.5.5">5.5.5</a>&nbsp;<a id="warn.199" href="#warn.199">199 Miscellaneous Warning</a></h3>
<h3 id="rfc.section.5.5.6"><a href="#rfc.section.5.5.6">5.5.6</a>&nbsp;<a id="warn.214" href="#warn.214">214 Transformation Applied</a></h3>
<h3 id="rfc.section.5.5.7"><a href="#rfc.section.5.5.7">5.5.7</a>&nbsp;<a id="warn.299" href="#warn.299">299 Miscellaneous Persistent Warning</a></h3>
<h3 id="rfc.section.5.5.8"><a href="#rfc.section.5.5.8">5.5.8</a>&nbsp;<a id="warn.code.extensions" href="#warn.code.extensions">Warn Code Extensions</a></h3>
<p id="rfc.section.5.5.8.p.1">Extension warn codes can be defined; see <a href="#warn.code.registry.procedure" title="Procedure">Section&nbsp;7.2.1</a> for details.
<h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="history.lists" href="#history.lists">History Lists</a></h1>
<h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a>&nbsp;<a id="cache.directive.registry" href="#cache.directive.registry">Cache Directive Registry</a></h2>
<p id="rfc.section.7.1.p.1">The HTTP Cache Directive Registry defines the name space for the cache directives. It will be created and maintained at &lt;<a href="http://www.iana.org/assignments/http-cache-directives">http://www.iana.org/assignments/http-cache-directives</a>&gt;.
<h3 id="rfc.section.7.1.1"><a href="#rfc.section.7.1.1">7.1.1</a>&nbsp;<a id="cache.directive.registry.procedure" href="#cache.directive.registry.procedure">Procedure</a></h3>
<h3 id="rfc.section.7.1.2"><a href="#rfc.section.7.1.2">7.1.2</a>&nbsp;<a id="cache.directive.considerations" href="#cache.directive.considerations">Considerations for New Cache Control Directives</a></h3>
<h3 id="rfc.section.7.1.3"><a href="#rfc.section.7.1.3">7.1.3</a>&nbsp;<a id="cache.directive.registration" href="#cache.directive.registration">Registrations</a></h3>
<h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a>&nbsp;<a id="warn.code.registry" href="#warn.code.registry">Warn Code Registry</a></h2>
<p id="rfc.section.7.2.p.1">The HTTP Warn Code Registry defines the name space for warn codes. It will be created and maintained at &lt;<a href="http://www.iana.org/assignments/http-warn-codes">http://www.iana.org/assignments/http-warn-codes</a>&gt;.
<h3 id="rfc.section.7.2.1"><a href="#rfc.section.7.2.1">7.2.1</a>&nbsp;<a id="warn.code.registry.procedure" href="#warn.code.registry.procedure">Procedure</a></h3>
<h3 id="rfc.section.7.2.2"><a href="#rfc.section.7.2.2">7.2.2</a>&nbsp;<a id="warn.code.registration" href="#warn.code.registration">Registrations</a></h3>
<td class="left"><a href="#warn.110" id="rfc.xref.warn.110.1" title="110 Response is Stale">Section&nbsp;5.5.1</a>
<td class="left"><a href="#warn.111" id="rfc.xref.warn.111.1" title="111 Revalidation Failed">Section&nbsp;5.5.2</a>
<td class="left"><a href="#warn.112" id="rfc.xref.warn.112.1" title="112 Disconnected Operation">Section&nbsp;5.5.3</a>
<td class="left"><a href="#warn.113" id="rfc.xref.warn.113.1" title="113 Heuristic Expiration">Section&nbsp;5.5.4</a>
<td class="left"><a href="#warn.199" id="rfc.xref.warn.199.1" title="199 Miscellaneous Warning">Section&nbsp;5.5.5</a>
<td class="left"><a href="#warn.214" id="rfc.xref.warn.214.1" title="214 Transformation Applied">Section&nbsp;5.5.6</a>
<td class="left"><a href="#warn.299" id="rfc.xref.warn.299.1" title="299 Miscellaneous Persistent Warning">Section&nbsp;5.5.7</a>
<td class="left"><a href="#header.warning" id="rfc.xref.header.warning.5" title="Warning">Section&nbsp;5.5</a>
<td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a> and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-latest">Hypertext Transfer Protocol (HTTP/1.1): Authentication</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p7-auth-latest (work in progress), September&nbsp;2013.
<address><span class="vcardline"><b>Mark Nottingham</b>
</span><span class="vcardline">Akamai</span><span class="vcardline">Email: <a href="mailto:mnot@mnot.net">mnot@mnot.net</a></span><span class="vcardline">URI: <a href="http://www.mnot.net/">http://www.mnot.net/</a></span></address>
<p id="rfc.section.A.p.15">Some requirements regarding production of the <a href="#header.warning" class="smpl">Warning</a> header fields have been relaxed, as it is not widely implemented. Furthermore, the <a href="#header.warning" class="smpl">Warning</a> header field no longer uses RFC 2047 encoding, nor allows multiple languages, as these aspects were not implemented. (<a href="#header.warning" id="rfc.xref.header.warning.6" title="Warning">Section&nbsp;5.5</a>)
<a href="#header.warning" class="smpl">warning-value</a> = warn-code SP warn-agent SP warn-text SP warn-date
<li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/307">http://tools.ietf.org/wg/httpbis/trac/ticket/307</a>&gt;: "untangle Cache-Control ABNF"
<li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/353">http://tools.ietf.org/wg/httpbis/trac/ticket/353</a>&gt;: "Multiple values in Cache-Control header fields"
<li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/355">http://tools.ietf.org/wg/httpbis/trac/ticket/355</a>&gt;: "Case sensitivity of header fields in CC values"
<li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/356">http://tools.ietf.org/wg/httpbis/trac/ticket/356</a>&gt;: "Spurious 'MAYs'"
<li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/360">http://tools.ietf.org/wg/httpbis/trac/ticket/360</a>&gt;: "enhance considerations for new cache control directives"
<li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/373">http://tools.ietf.org/wg/httpbis/trac/ticket/373</a>&gt;: "broken prose in description of 'Vary'"
<li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/375">http://tools.ietf.org/wg/httpbis/trac/ticket/375</a>&gt;: "'Most Conservative'"
<li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/453">http://tools.ietf.org/wg/httpbis/trac/ticket/453</a>&gt;: "Returning the freshest response"
<li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/469">http://tools.ietf.org/wg/httpbis/trac/ticket/469</a>&gt;: "Editorial notes for p6"
<li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/471">http://tools.ietf.org/wg/httpbis/trac/ticket/471</a>&gt;: "Vary and future requests"
<h2 id="rfc.section.D.5"><a href="#rfc.section.D.5">D.5</a>&nbsp;<a id="changes.since.23" href="#changes.since.23">Since draft-ietf-httpbis-p6-cache-23</a></h2>
<li>110 Response is Stale (warn code)&nbsp;&nbsp;<a href="#rfc.iref.50"><b>5.5.1</b></a>, <a href="#rfc.xref.warn.110.1">7.2.2</a></li>
<li>111 Revalidation Failed (warn code)&nbsp;&nbsp;<a href="#rfc.iref.50"><b>5.5.2</b></a>, <a href="#rfc.xref.warn.111.1">7.2.2</a></li>
<li>112 Disconnected Operation (warn code)&nbsp;&nbsp;<a href="#rfc.iref.50"><b>5.5.3</b></a>, <a href="#rfc.xref.warn.112.1">7.2.2</a></li>
<li>113 Heuristic Expiration (warn code)&nbsp;&nbsp;<a href="#rfc.iref.50"><b>5.5.4</b></a>, <a href="#rfc.xref.warn.113.1">7.2.2</a></li>
<li>199 Miscellaneous Warning (warn code)&nbsp;&nbsp;<a href="#rfc.iref.50"><b>5.5.5</b></a>, <a href="#rfc.xref.warn.199.1">7.2.2</a></li>
<li>214 Transformation Applied (warn code)&nbsp;&nbsp;<a href="#rfc.iref.50"><b>5.5.6</b></a>, <a href="#rfc.xref.warn.214.1">7.2.2</a></li>
<li>299 Miscellaneous Persistent Warning (warn code)&nbsp;&nbsp;<a href="#rfc.iref.50"><b>5.5.7</b></a>, <a href="#rfc.xref.warn.299.1">7.2.2</a></li>
<li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">2</a>, <a href="#rfc.xref.Part2.2">2</a>, <a href="#rfc.xref.Part2.3">4</a>, <a href="#rfc.xref.Part2.4">4.1</a>, <a href="#rfc.xref.Part2.5">4.2.3</a>, <a href="#rfc.xref.Part2.6">4.4</a>, <a href="#rfc.xref.Part2.7">5.3</a>, <a href="#rfc.xref.Part2.8">8</a>, <a href="#Part2"><b>10.1</b></a>, <a href="#rfc.xref.Part2.9">B</a><ul>
<li><em>Section 4.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">4</a>, <a href="#rfc.xref.Part2.6">4.4</a></li>
<li><em>Section 7.1.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">5.3</a>, <a href="#rfc.xref.Part2.9">B</a></li>
<li><em>Part4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">4.2.2</a>, <a href="#rfc.xref.Part4.2">4.3</a>, <a href="#rfc.xref.Part4.3">4.3.1</a>, <a href="#rfc.xref.Part4.4">4.3.1</a>, <a href="#rfc.xref.Part4.5">4.3.2</a>, <a href="#rfc.xref.Part4.6">4.3.2</a>, <a href="#rfc.xref.Part4.7">4.3.2</a>, <a href="#rfc.xref.Part4.8">4.3.2</a>, <a href="#rfc.xref.Part4.9">4.3.2</a>, <a href="#rfc.xref.Part4.10">4.3.4</a>, <a href="#Part4"><b>10.1</b></a><ul>
<li><em>Section 2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.10">4.3.4</a></li>
<li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.6">4.3.2</a></li>
<li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.8">4.3.2</a></li>
<li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.9">4.3.2</a></li>
<li><em>Section 3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.7">4.3.2</a></li>
<li>Warning header field&nbsp;&nbsp;<a href="#rfc.xref.header.warning.1">3.3</a>, <a href="#rfc.xref.header.warning.2">4.2.4</a>, <a href="#rfc.xref.header.warning.3">4.3.4</a>, <a href="#rfc.xref.header.warning.4">4.3.5</a>, <a href="#rfc.iref.w.1"><b>5.5</b></a>, <a href="#rfc.xref.header.warning.5">7.3</a>, <a href="#rfc.xref.header.warning.6">A</a></li>