Source: https://trac.ietf.org/trac/httpbis/changeset/442/draft-ietf-httpbis
Timestamp: 2020-02-28 15:44:00
Document Index: 509256654

Matched Legal Cases: ['art1', 'art1', 'art 1', 'art1', 'art1', 'art1', 'art 1', 'art1', 'art1', 'art1', 'art 1', 'art1', 'art1', 'art1', 'art 1', 'art1', 'art1', 'art1', 'art 1', 'art1', 'art1', 'art1', 'art 1', 'art1', 'art1', 'art1', 'art 1', 'art1', 'art7', 'art7', 'art 7', 'art7', 'art1', 'art1', 'art 1', 'art1', 'art2', 'art2', 'art 2', 'art2', 'art1', 'art1', 'art 1', 'art1', 'art1', 'art1', 'art 1', 'art1', 'art3', 'art3', 'art 3', 'art3', 'art5', 'art5', 'art 5', 'art5', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art2', 'art2', 'art2', 'art2', 'art3', 'art3', 'art3', 'art3', 'art3', 'art4', 'art4', 'art4', 'art4', 'art4', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art7', 'art7', 'art7', 'art7', 'art7', 'art7']

Changeset 442 for draft-ietf-httpbis – Hypertext Transfer Protocol Wiki
Changeset 442 for draft-ietf-httpbis
02/02/09 20:18:21 (11 years ago)
Bring ABNF stuff in-line with main branch.
p6-cache.html (modified) (58 diffs)
p6-cache.xml (modified) (16 diffs)
<link rel="Chapter" title="3 Cache Operation" href="#rfc.section.3">
<link rel="Chapter" title="5 History Lists" href="#rfc.section.5">
<li class="tocline0">3.&nbsp;&nbsp;&nbsp;<a href="#caching.overview">Cache Operation</a><ul class="toc">
<li class="tocline1">3.1&nbsp;&nbsp;&nbsp;<a href="#response.cacheability">Response Cacheability</a><ul class="toc">
<li class="tocline1">3.1.1&nbsp;&nbsp;&nbsp;<a href="#errors.or.incomplete.response.cache.behavior">Storing Incomplete Responses</a></li>
<li class="tocline1">3.2&nbsp;&nbsp;&nbsp;<a href="#constructing.responses.from.caches">Constructing Responses from Caches</a></li>
<li class="tocline1">3.3&nbsp;&nbsp;&nbsp;<a href="#expiration.model">Freshness Model</a><ul class="toc">
<li class="tocline1">3.3.1&nbsp;&nbsp;&nbsp;<a href="#calculating.freshness.lifetime">Calculating Freshness Lifetime</a><ul class="toc">
<li class="tocline1">3.3.1.1&nbsp;&nbsp;&nbsp;<a href="#heuristic.freshness">Using Heuristic Freshness</a></li>
<li class="tocline1">3.3.2&nbsp;&nbsp;&nbsp;<a href="#age.calculations">Calculating Age</a></li>
<li class="tocline1">3.3.3&nbsp;&nbsp;&nbsp;<a href="#serving.stale.responses">Serving Stale Responses</a></li>
<li class="tocline1">3.4&nbsp;&nbsp;&nbsp;<a href="#validation.model">Validation Model</a></li>
<li class="tocline1">3.5&nbsp;&nbsp;&nbsp;<a href="#invalidation.after.updates.or.deletions">Request Methods that Invalidate</a></li>
<li class="tocline1">3.6&nbsp;&nbsp;&nbsp;<a href="#caching.negotiated.responses">Caching Negotiated Responses</a></li>
<li class="tocline1">3.7&nbsp;&nbsp;&nbsp;<a href="#combining.headers">Combining Responses</a></li>
<li class="tocline1">4.1&nbsp;&nbsp;&nbsp;<a href="#header.age">Age</a></li>
<li class="tocline1">4.2&nbsp;&nbsp;&nbsp;<a href="#header.cache-control">Cache-Control</a><ul class="toc">
<li class="tocline1">4.2.1&nbsp;&nbsp;&nbsp;<a href="#cache-request-directive">Request Cache-Control Directives</a></li>
<li class="tocline1">4.2.2&nbsp;&nbsp;&nbsp;<a href="#cache-response-directive">Response Cache-Control Directives</a></li>
<li class="tocline1">4.2.3&nbsp;&nbsp;&nbsp;<a href="#cache.control.extensions">Cache Control Extensions</a></li>
<li class="tocline1">4.3&nbsp;&nbsp;&nbsp;<a href="#header.expires">Expires</a></li>
<li class="tocline1">4.4&nbsp;&nbsp;&nbsp;<a href="#header.pragma">Pragma</a></li>
<li class="tocline1">4.5&nbsp;&nbsp;&nbsp;<a href="#header.vary">Vary</a></li>
<li class="tocline1">4.6&nbsp;&nbsp;&nbsp;<a href="#header.warning">Warning</a></li>
<li class="tocline0">5.&nbsp;&nbsp;&nbsp;<a href="#history.lists">History Lists</a></li>
request, reducing latency and network round-trips; a "freshness" mechanism is used for this purpose (see <a href="#expiration.model" title="Freshness Model">Section&nbsp;3.3</a>). Even when a new request is required, it is often possible to reuse all or parts of the payload of a prior response to satisfy
the request, thereby reducing network bandwidth usage; a "validation" mechanism is used for this purpose (see <a href="#validation.model" title="Validation Model">Section&nbsp;3.4</a>).
<p id="rfc.section.2.p.1">This specification uses the ABNF syntax defined in <a href="p1-messaging.html#notation.abnf" title="ABNF Extension: #rule">Section 1.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> and the core rules defined in <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>: <span class="comment">[abnf.dep: ABNF syntax and basic rules will be adopted from RFC 5234, see &lt;<a href="http://ietf.org/wg/httpbis/trac/ticket/36">http://ietf.org/wg/httpbis/trac/ticket/36</a>&gt;.]</span>
<div id="rfc.figure.u.1"></div> <pre class="inline"> <a href="#notation" class="smpl">DIGIT</a> = &lt;DIGIT, defined in <a href="#Part1" id="rfc.xref.Part1.3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>&gt;
</pre> <div id="rfc.figure.u.2"></div> <pre class="inline"> <a href="#notation" class="smpl">quoted-string</a> = &lt;quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>&gt;
</pre> <div id="abnf.dependencies">
<div id="rfc.figure.u.3"></div> <pre class="inline"> <a href="#abnf.dependencies" class="smpl">field-name</a> = &lt;field-name, defined in <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#message.headers" title="Message Headers">Section 4.2</a>&gt;
<a href="#abnf.dependencies" class="smpl">port</a> = &lt;port, defined in <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.1</a>&gt;
<a href="#abnf.dependencies" class="smpl">uri-host</a> = &lt;uri-host, defined in <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.1</a>&gt;
</pre> <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="caching.overview" href="#caching.overview">Cache Operation</a></h1>
<h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a id="response.cacheability" href="#response.cacheability">Response Cacheability</a></h2>
<p id="rfc.section.3.1.p.1">A cache <em class="bcp14">MAY</em> store a response to any request, provided that:
<li>the "no-store" cache directive (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.1" title="Cache-Control">Section&nbsp;4.2</a>) does not appear in request or response headers.
<li>the cache understands partial responses, if the response is partial or incomplete (see <a href="#errors.or.incomplete.response.cache.behavior" title="Storing Incomplete Responses">Section&nbsp;3.1.1</a>).
<h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="constructing.responses.from.caches" href="#constructing.responses.from.caches">Constructing Responses from Caches</a></h2>
<p id="rfc.section.3.2.p.1">For a given request, a non-shared cache <em class="bcp14">MAY</em> return a stored response, provided that:
<li>the stored response is either fresh (see <a href="#expiration.model" title="Freshness Model">Section&nbsp;3.3</a>) or allowed to be served stale (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section&nbsp;3.3.3</a>), and
<li>the presented request and stored response are free from directives that would prevent it (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.2" title="Cache-Control">Section&nbsp;4.2</a> and <a href="#header.pragma" id="rfc.xref.header.pragma.1" title="Pragma">Section&nbsp;4.4</a>).
<li>the criteria for non-shared caches above are met (including directives for shared caches; see <a href="#header.cache-control" id="rfc.xref.header.cache-control.3" title="Cache-Control">Section&nbsp;4.2</a>), and
<li>the stored response was not associated with an authenticated request (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>), unless explicitly allowed (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.4" title="Cache-Control">Section&nbsp;4.2</a>).
<p id="rfc.section.3.2.p.4">All responses satisfied from cache <em class="bcp14">MUST</em> include an appropriate Age header field (<a href="#header.age" id="rfc.xref.header.age.1" title="Age">Section&nbsp;4.1</a>).
<p id="rfc.section.3.2.p.5">All request methods other than GET and HEAD <em class="bcp14">MUST</em> be written through the cache to the origin server. Note that such requests might invalidate already stored responses; see <a href="#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section&nbsp;3.5</a>.
<p id="rfc.section.3.2.p.6">Caches <em class="bcp14">SHOULD</em> use the most recent response (as determined by the Date header) when more than one applicable response is stored. They <em class="bcp14">MAY</em> also send a request with "Cache-Control: max-age=0" or "Cache-Control: no-cache" to disambiguate which response to use.
agent to refresh its display or reload a resource; its semantics apply only to caches. See <a href="#history.lists" title="History Lists">Section&nbsp;5</a> for an explanation of the difference between caches and history mechanisms.
<p id="rfc.section.3.3.p.4">If an origin server wishes to force a cache to validate every request, it <em class="bcp14">MAY</em> assign an explicit expiration time in the past. This means that the response is always stale, so that caches should validate
<p id="rfc.section.3.3.p.5">Since origin servers do not always provide explicit expiration times, HTTP caches may assign heuristic expiration times when
<p id="rfc.section.3.3.p.6">The calculation to determine if a response has expired is:</p>
<div id="rfc.figure.u.4"></div> <pre class="text"> response_is_fresh = (freshness_lifetime &gt; current_age)
</pre> <p id="rfc.section.3.3.p.8">The freshness_lifetime is defined in <a href="#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section&nbsp;3.3.1</a>; the current_age is defined in <a href="#age.calculations" title="Calculating Age">Section&nbsp;3.3.2</a>.
<p id="rfc.section.3.3.p.9">Additionally, clients may need to influence freshness calculation. They can do this using several request cache directives,
<p id="rfc.section.3.3.1.p.1">A cache can calculate the freshness lifetime (denoted as freshness_lifetime) of a response by using the first match of: </p>
<li>If the cache is shared and the s-maxage response cache directive (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;4.2.2</a>) is present, use its value, or
<li>If the max-age response cache directive (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;4.2.2</a>) is present, use its value, or
<li>If the Expires response header (<a href="#header.expires" id="rfc.xref.header.expires.2" title="Expires">Section&nbsp;4.3</a>) is present, use its value minus the value of the Date response header, or
<li>Otherwise, no explicit expiration time is present in the response, but a heuristic may be used; see <a href="#heuristic.freshness" title="Using Heuristic Freshness">Section&nbsp;3.3.1.1</a>.
<p id="rfc.section.3.3.1.p.2">Note that this calculation is not vulnerable to clock skew, since all of the information comes from the origin server.</p>
<h4 id="rfc.section.3.3.1.1"><a href="#rfc.section.3.3.1.1">3.3.1.1</a>&nbsp;<a id="heuristic.freshness" href="#heuristic.freshness">Using Heuristic Freshness</a></h4>
<p id="rfc.section.3.3.1.1.p.1">If no explicit expiration time is present in a stored response that has a status code of 200, 203, 206, 300, 301 or 410, a
<p id="rfc.section.3.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
<p id="rfc.section.3.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
<p id="rfc.section.3.3.2.p.2">When a response is generated from a stored response, the cache <em class="bcp14">MUST</em> include a single Age header field in the response with a value equal to the stored response's current_age, calculated using
<p id="rfc.section.3.3.2.p.3">The term "age_value" denotes the value of the Age header, in a form appropriate for arithmetic operations.</p>
<p id="rfc.section.3.3.2.p.4">HTTP/1.1 requires origin servers to send a Date header, if possible, with every response, giving the time at which the response
was generated (see <a href="p1-messaging.html#header.date" title="Date">Section 8.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>). The term "date_value" denotes the value of the Date header, in a form appropriate for arithmetic operations.
<p id="rfc.section.3.3.2.p.5">The term "now" means "the current value of the clock at the host performing the calculation." Hosts that use HTTP, but especially
<p id="rfc.section.3.3.2.p.6">A response's age can be calculated in two entirely independent ways: </p>
<p id="rfc.section.3.3.2.p.7">These are combined as</p>
<div id="rfc.figure.u.5"></div> <pre class="text"> corrected_received_age = max(now - date_value, age_value)
</pre> <p id="rfc.section.3.3.2.p.9">When an Age value is received, it <em class="bcp14">MUST</em> be interpreted relative to the time the request was initiated, not the time that the response was received.
<div id="rfc.figure.u.6"></div> <pre class="text"> corrected_initial_age = corrected_received_age
</pre> <p id="rfc.section.3.3.2.p.11">where "request_time" is the time (according to the local clock) when the request that elicited this response was sent.</p>
<p id="rfc.section.3.3.2.p.12">The current_age of a stored response can then be calculated by adding the amount of time (in seconds) since the stored response
<p id="rfc.section.3.3.2.p.13">In summary:</p>
<div id="rfc.figure.u.7"></div> <pre class="text"> /*
</pre> <h3 id="rfc.section.3.3.3"><a href="#rfc.section.3.3.3">3.3.3</a>&nbsp;<a id="serving.stale.responses" href="#serving.stale.responses">Serving Stale Responses</a></h3>
<p id="rfc.section.3.3.3.p.1">A "stale" response is one that either has explicit expiry information, or is allowed to have heuristic expiry calculated,
but is not fresh according to the calculations in <a href="#expiration.model" title="Freshness Model">Section&nbsp;3.3</a>.
<p id="rfc.section.3.3.3.p.2">Caches <em class="bcp14">MUST NOT</em> return a stale response if it is prohibited by an explicit in-protocol directive (e.g., by a "no-store" or "no-cache" cache
see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;4.2.2</a>).
<p id="rfc.section.3.3.3.p.3">Caches <em class="bcp14">MAY</em> return a stale response if disconnected or explicitly allowed (e.g., the max-stale request directive; see <a href="#cache-request-directive" title="Request Cache-Control Directives">Section&nbsp;4.2.1</a>).
<h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a>&nbsp;<a id="validation.model" href="#validation.model">Validation Model</a></h2>
<p id="rfc.section.3.4.p.1">When a cache has a stale response that it would like to use, it <em class="bcp14">SHOULD</em> first check with the origin server (or possibly an intermediate cache with a fresh response) to see if it is still usable.
<p id="rfc.section.3.4.p.3">See <a href="#combining.headers" title="Combining Responses">Section&nbsp;3.7</a> regarding combining cached headers with those in a 304 response.
<p id="rfc.section.3.4.p.4">If a cache receives a 5xx response while attempting to validate a response, it <em class="bcp14">MAY</em> either forward this response to the requesting client, or act as if the server failed to respond. In the latter case, it <em class="bcp14">MAY</em> return a previously received response unless the stored response includes the "must-revalidate" cache directive (see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;4.2.2</a>).
<h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a>&nbsp;<a id="invalidation.after.updates.or.deletions" href="#invalidation.after.updates.or.deletions">Request Methods that Invalidate</a></h2>
<p id="rfc.section.3.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.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> have the potential for changing state on the origin server, intervening caches have the opportunity to use them to keep their
<p id="rfc.section.3.5.p.2">The following HTTP methods <em class="bcp14">MUST</em> cause a cache to invalidate the Request-URI as well as the Location and Content-Location headers (if present):
<p id="rfc.section.3.5.p.3">An invalidation based on the URI in 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 Request-URI. This helps prevent denial of service
<p id="rfc.section.3.5.p.6">Here, "invalidate" means that the cache will either remove all stored responses related to the Request-URI, or will mark these
<p id="rfc.section.3.5.p.7">Note that this does not guarantee that all appropriate responses are invalidated. For example, the request that caused the
<p id="rfc.section.3.6.p.4">A Vary header field-value of "*" always fails to match, and subsequent requests on that resource can only be properly interpreted
<p id="rfc.section.3.6.p.5">If the selecting request header fields for the stored response do not match the selecting request header fields of the new
<p id="rfc.section.3.6.p.6">If one or more applicable stored response has an entity tag, the forwarded request <em class="bcp14">SHOULD</em> be conditional and include all of these entity tags in an If-None-Match header field. This conveys to the server the set of
<p id="rfc.section.3.6.p.7">If any of the existing stored responses contains only partial content for the associated entity, 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
<p id="rfc.section.3.6.p.8">If a cache receives a successful response whose Content-Location field matches that of an existing stored response for the
<p id="rfc.section.3.7.p.1">When a cache receives a 304 (Not Modified) response or a 206 (Partial Content) response, it needs to update the stored response
<p id="rfc.section.3.7.p.2">If the status code is 304 (Not Modified), the cache <em class="bcp14">SHOULD</em> use the stored entity-body as the updated entity-body. If the status code is 206 (Partial Content) and the ETag or Last-Modified
<p id="rfc.section.3.7.p.3">The stored response headers are used for the updated response, except that </p>
<li>any stored Warning headers with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.2" title="Warning">Section&nbsp;4.6</a>) <em class="bcp14">MUST</em> be deleted from the stored response and the forwarded response.
<p id="rfc.section.3.7.p.4">A cache <em class="bcp14">MUST</em> also replace stored headers with corresponding headers received in the incoming response, except for Warning headers as described
<p id="rfc.section.4.p.2">For entity-header fields, both sender and recipient refer to either the client or the server, depending on who sends and who
<h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a id="header.age" href="#header.age">Age</a></h2>
<p id="rfc.section.4.1.p.1">The Age response-header field conveys the sender's estimate of the amount of time since the response (or its validation) was
generated at the origin server. Age values are calculated as specified in <a href="#age.calculations" title="Calculating Age">Section&nbsp;3.3.2</a>.
<div id="rfc.figure.u.8"></div> <pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span> <a href="#header.age" class="smpl">Age</a> = "Age" ":" <a href="#header.age" class="smpl">age-value</a>
</pre> <div id="rule.delta-seconds">
<p id="rfc.section.4.1.p.3"> Age field-values are non-negative decimal integers, representing time in seconds.</p>
<div id="rfc.figure.u.9"></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>
</pre> <p id="rfc.section.4.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,
<p id="rfc.section.4.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
<h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a id="header.cache-control" href="#header.cache-control">Cache-Control</a></h2>
<p id="rfc.section.4.2.p.1">The Cache-Control general-header field is used to specify directives that <em class="bcp14">MUST</em> be obeyed by all caches along the request/response chain. The directives specify behavior intended to prevent caches from
<dd>Note that HTTP/1.0 caches might not implement Cache-Control and might only implement Pragma: no-cache (see <a href="#header.pragma" id="rfc.xref.header.pragma.2" title="Pragma">Section&nbsp;4.4</a>).
<p id="rfc.section.4.2.p.2">Cache directives <em class="bcp14">MUST</em> be passed through by a proxy or gateway application, regardless of their significance to that application, since the directives
<div id="rfc.figure.u.10"></div> <pre class="inline"><span id="rfc.iref.g.4"></span><span id="rfc.iref.g.5"></span><span id="rfc.iref.g.6"></span> <a href="#header.cache-control" class="smpl">Cache-Control</a> = "Cache-Control" ":" 1#<a href="#header.cache-control" class="smpl">cache-directive</a>
<a href="#header.cache-control" class="smpl">cache-directive</a> = <a href="#cache-request-directive" class="smpl">cache-request-directive</a>
/ <a href="#cache-response-directive" class="smpl">cache-response-directive</a>
</pre> <h3 id="rfc.section.4.2.1"><a href="#rfc.section.4.2.1">4.2.1</a>&nbsp;<a id="cache-request-directive" href="#cache-request-directive">Request Cache-Control Directives</a></h3>
<div id="rfc.figure.u.11"></div> <pre class="inline"><span id="rfc.iref.g.7"></span> <a href="#cache-request-directive" class="smpl">cache-request-directive</a> =
</pre> <p id="rfc.section.4.2.1.p.2"> <span id="rfc.iref.c.4"></span> <span id="rfc.iref.n.1"></span> no-cache
<p id="rfc.section.4.2.1.p.3"> <span id="rfc.iref.c.5"></span> <span id="rfc.iref.n.2"></span> no-store
<p id="rfc.section.4.2.1.p.4"> <span id="rfc.iref.c.6"></span> <span id="rfc.iref.m.1"></span> max-age
<p id="rfc.section.4.2.1.p.5"> <span id="rfc.iref.c.7"></span> <span id="rfc.iref.m.2"></span> max-stale
<p id="rfc.section.4.2.1.p.6"> <span id="rfc.iref.c.8"></span> <span id="rfc.iref.m.3"></span> min-fresh
<p id="rfc.section.4.2.1.p.7"> <span id="rfc.iref.c.9"></span> <span id="rfc.iref.n.3"></span> no-transform
<p id="rfc.section.4.2.1.p.8"> <span id="rfc.iref.c.10"></span> <span id="rfc.iref.o.1"></span> only-if-cached
<h3 id="rfc.section.4.2.2"><a href="#rfc.section.4.2.2">4.2.2</a>&nbsp;<a id="cache-response-directive" href="#cache-response-directive">Response Cache-Control Directives</a></h3>
<div id="rfc.figure.u.12"></div> <pre class="inline"><span id="rfc.iref.g.8"></span> <a href="#cache-response-directive" class="smpl">cache-response-directive</a> =
</pre> <p id="rfc.section.4.2.2.p.2"> <span id="rfc.iref.c.11"></span> <span id="rfc.iref.p.1"></span> public
<p id="rfc.section.4.2.2.p.3"> <span id="rfc.iref.c.12"></span> <span id="rfc.iref.p.2"></span> private
<p id="rfc.section.4.2.2.p.4"> <span id="rfc.iref.c.13"></span> <span id="rfc.iref.n.4"></span> no-cache
<p id="rfc.section.4.2.2.p.5"> <span id="rfc.iref.c.14"></span> <span id="rfc.iref.n.5"></span> no-store
<p id="rfc.section.4.2.2.p.6"> <span id="rfc.iref.c.15"></span> <span id="rfc.iref.m.4"></span> must-revalidate
<p id="rfc.section.4.2.2.p.7"> <span id="rfc.iref.c.16"></span> <span id="rfc.iref.p.3"></span> proxy-revalidate
<p id="rfc.section.4.2.2.p.8"> <span id="rfc.iref.c.17"></span> <span id="rfc.iref.m.5"></span> max-age
<p id="rfc.section.4.2.2.p.9"> <span id="rfc.iref.c.18"></span> <span id="rfc.iref.s.2"></span> s-maxage
<p id="rfc.section.4.2.2.p.10"> <span id="rfc.iref.c.19"></span> <span id="rfc.iref.n.6"></span> no-transform
<h3 id="rfc.section.4.2.3"><a href="#rfc.section.4.2.3">4.2.3</a>&nbsp;<a id="cache.control.extensions" href="#cache.control.extensions">Cache Control Extensions</a></h3>
<p id="rfc.section.4.2.3.p.1">The Cache-Control header field can be extended through the use of one or more cache-extension tokens, each with an optional
<p id="rfc.section.4.2.3.p.2">This extension mechanism depends on an HTTP cache obeying all of the cache-control directives defined for its native HTTP-version,
<p id="rfc.section.4.2.3.p.3">For example, consider a hypothetical new response directive called "community" which acts as a modifier to the private directive.
<div id="rfc.figure.u.13"></div> <pre class="text"> Cache-Control: private, community="UCI"
</pre> <p id="rfc.section.4.2.3.p.5">A cache seeing this header field will act correctly even if the cache does not understand the community cache-extension, since
<p id="rfc.section.4.2.3.p.6">Unrecognized cache directives <em class="bcp14">MUST</em> be ignored; it is assumed that any cache directive likely to be unrecognized by an HTTP/1.1 cache will be combined with standard
<h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a>&nbsp;<a id="header.expires" href="#header.expires">Expires</a></h2>
<p id="rfc.section.4.3.p.1">The Expires entity-header field gives the date/time after which the response is considered stale. See <a href="#expiration.model" title="Freshness Model">Section&nbsp;3.3</a> for further discussion of the expiration model.
<p id="rfc.section.4.3.p.2">The presence of an Expires field does not imply that the original resource will change or cease to exist at, before, or after
<p id="rfc.section.3.3.p.1">The Expires entity-header field gives the date/time after which the response is considered stale. See <a href="#expiration.model" title="Freshness Model">Section&nbsp;2.3</a> for further discussion of the expiration model.
<p id="rfc.section.4.3.p.3">The field-value is an absolute date and time as defined by HTTP-date in <a href="p1-messaging.html#full.date" title="Full Date">Section 3.2.1</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>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format.
<div id="rfc.figure.u.14"></div> <pre class="inline"><span id="rfc.iref.g.9"></span> <a href="#header.expires" class="smpl">Expires</a> = "Expires" ":" <a href="#abnf.dependencies" class="smpl">HTTP-date</a>
</pre> <p id="rfc.section.4.3.p.5">For example</p>
<div id="rfc.figure.u.15"></div> <pre class="text"> Expires: Thu, 01 Dec 1994 16:00:00 GMT
</pre> <p id="rfc.section.4.3.p.7"> </p>
<dd> <b>Note:</b> if a response includes a Cache-Control field with the max-age directive (see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;4.2.2</a>), that directive overrides the Expires field.
<p id="rfc.section.4.3.p.8">HTTP/1.1 servers <em class="bcp14">SHOULD NOT</em> send Expires dates more than one year in the future.
<p id="rfc.section.4.3.p.9">HTTP/1.1 clients and caches <em class="bcp14">MUST</em> treat other invalid date formats, especially including the value "0", as in the past (i.e., "already expired").
<h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a>&nbsp;<a id="header.pragma" href="#header.pragma">Pragma</a></h2>
<p id="rfc.section.4.4.p.1">The Pragma general-header field is used to include implementation-specific directives that might apply to any recipient along
<div id="rfc.figure.u.16"></div> <pre class="inline"><span id="rfc.iref.g.10"></span><span id="rfc.iref.g.11"></span><span id="rfc.iref.g.12"></span> <a href="#header.pragma" class="smpl">Pragma</a> = "Pragma" ":" 1#<a href="#header.pragma" class="smpl">pragma-directive</a>
</pre> <p id="rfc.section.4.4.p.3">When the no-cache directive is present in a request message, an application <em class="bcp14">SHOULD</em> forward the request toward the origin server even if it has a cached copy of what is being requested. This pragma directive
has the same semantics as the no-cache response directive (see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;4.2.2</a>) and is defined here for backward compatibility with HTTP/1.0. Clients <em class="bcp14">SHOULD</em> include both header fields when a no-cache request is sent to a server not known to be HTTP/1.1 compliant. HTTP/1.1 caches <em class="bcp14">SHOULD</em> treat "Pragma: no-cache" as if the client had sent "Cache-Control: no-cache".
<p id="rfc.section.4.4.p.4"> </p>
<p id="rfc.section.4.4.p.5">This mechanism is deprecated; no new Pragma directives will be defined in HTTP.</p>
<h2 id="rfc.section.4.5"><a href="#rfc.section.4.5">4.5</a>&nbsp;<a id="header.vary" href="#header.vary">Vary</a></h2>
<p id="rfc.section.4.5.p.1">The Vary response-header field's value indicates the set of request-header fields that fully determines, while the response
response is the appropriate representation. See <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;3.6</a> for use of the Vary header field by caches.
<div id="rfc.figure.u.17"></div> <pre class="inline"><span id="rfc.iref.g.13"></span> <a href="#header.vary" class="smpl">Vary</a> = "Vary" ":" ( "*" / 1#<a href="#abnf.dependencies" class="smpl">field-name</a> )
</pre> <p id="rfc.section.4.5.p.3">The set of header fields named by the Vary field value is known as the "selecting" request-headers.</p>
<p id="rfc.section.4.5.p.4">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
<p id="rfc.section.4.5.p.5">A Vary field value of "*" signals that unspecified parameters not limited to the request-headers (e.g., the network address
<p id="rfc.section.4.5.p.6">The field-names given are not limited to the set of standard request-header fields defined by this specification. Field names
<h2 id="rfc.section.4.6"><a href="#rfc.section.4.6">4.6</a>&nbsp;<a id="header.warning" href="#header.warning">Warning</a></h2>
<p id="rfc.section.4.6.p.1">The Warning general-header field is used to carry additional information about the status or transformation of a message which
might not be reflected in the message. This information is typically used to warn about possible incorrectness introduced
<p id="rfc.section.4.6.p.2">Warnings can be used for other purposes, both cache-related and otherwise. The use of a warning, rather than an error status
<p id="rfc.section.4.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
<div id="rfc.figure.u.18"></div> <pre class="inline"><span id="rfc.iref.g.14"></span><span id="rfc.iref.g.15"></span><span id="rfc.iref.g.16"></span><span id="rfc.iref.g.17"></span><span id="rfc.iref.g.18"></span><span id="rfc.iref.g.19"></span> <a href="#header.warning" class="smpl">Warning</a> = "Warning" ":" 1#<a href="#header.warning" class="smpl">warning-value</a>
</pre> <p id="rfc.section.4.6.p.5">Multiple warnings <em class="bcp14">MAY</em> be attached to a response (either by the origin server or by a cache), including multiple warnings with the same code number.
<p id="rfc.section.4.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. If it is not possible to inform
<p id="rfc.section.4.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.
<p id="rfc.section.4.6.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.4.6.p.9">The warn-text <em class="bcp14">SHOULD</em> be in a natural language and character set that is most likely to be intelligible to the human user receiving the response.
<p id="rfc.section.4.6.p.10">If a character set other than ISO-8859-1 is used, it <em class="bcp14">MUST</em> be encoded in the warn-text using the method described in <a href="#RFC2047" id="rfc.xref.RFC2047.1"><cite title="MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text">[RFC2047]</cite></a>.
<p id="rfc.section.4.6.p.11">If an implementation sends a message with one or more Warning headers to a receiver whose version is HTTP/1.0 or lower, then
<p id="rfc.section.4.6.p.12">If an implementation receives a message with a warning-value that includes a warn-date, and that warn-date is different from
<p id="rfc.section.4.6.p.13">The following warn-codes are defined by this specification, each with a recommended warn-text in English, and a description
<p id="rfc.section.4.6.p.14">110 Response is stale </p>
<p id="rfc.section.4.6.p.15">111 Revalidation failed </p>
<p id="rfc.section.4.6.p.16">112 Disconnected operation </p>
<p id="rfc.section.4.6.p.17">113 Heuristic expiration </p>
<p id="rfc.section.4.6.p.18">199 Miscellaneous warning </p>
<p id="rfc.section.4.6.p.19">214 Transformation applied </p>
<p id="rfc.section.4.6.p.20">299 Miscellaneous persistent warning </p>
<h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="history.lists" href="#history.lists">History Lists</a></h1>
<p id="rfc.section.5.p.1">User agents often have history mechanisms, such as "Back" buttons and history lists, which can be used to redisplay an entity
<p id="rfc.section.5.p.2">History mechanisms and caches are different. In particular history mechanisms <em class="bcp14">SHOULD NOT</em> try to show a correct view of the current state of a resource. Rather, a history mechanism is meant to show exactly what the
<p id="rfc.section.5.p.3">By default, an expiration time does not apply to history mechanisms. If the entity is still in storage, a history mechanism <em class="bcp14">SHOULD</em> display it even if the entity has expired, unless the user has specifically configured the agent to refresh expired history
<p id="rfc.section.5.p.4">This is not to be construed to prohibit the history mechanism from telling the user that a view might be stale. </p>
<td> <a href="#header.age" id="rfc.xref.header.age.2" title="Age">Section&nbsp;4.1</a>
<td> <a href="#header.cache-control" id="rfc.xref.header.cache-control.5" title="Cache-Control">Section&nbsp;4.2</a>
<td> <a href="#header.expires" id="rfc.xref.header.expires.3" title="Expires">Section&nbsp;4.3</a>
<td> <a href="#header.pragma" id="rfc.xref.header.pragma.3" title="Pragma">Section&nbsp;4.4</a>
<td> <a href="#header.vary" id="rfc.xref.header.vary.2" title="Vary">Section&nbsp;4.5</a>
<td> <a href="#header.warning" id="rfc.xref.header.warning.3" title="Warning">Section&nbsp;4.6</a>
<p id="rfc.section.7.p.1">Caches expose additional potential vulnerabilities, since the contents of the cache represent an attractive target for malicious
<p id="rfc.section.8.p.1">Much of the content and presentation of the caching design is due to suggestions and comments from individuals including:
computed. (see also <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a> and <a href="#Part5" id="rfc.xref.Part5.4"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>)
needed headers in a 206 response, this problem can be avoided. (<a href="#combining.headers" title="Combining Responses">Section&nbsp;3.7</a>)
<p id="rfc.section.A.1.p.6">Warnings could be cached incorrectly, or not updated appropriately. <a href="#expiration.model" title="Freshness Model">3.3</a>, <a href="#combining.headers" title="Combining Responses">3.7</a>, <a href="#header.cache-control" id="rfc.xref.header.cache-control.7" title="Cache-Control">4.2</a>, and <a href="#header.warning" id="rfc.xref.header.warning.4" title="Warning">4.6</a>) Warning also needed to be a general header, as PUT or other methods may have need for it in requests.
<p id="rfc.section.A.2.p.1">Clarify denial of service attack avoidance requirement. (<a href="#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section&nbsp;3.5</a>)
<li class="indline1">Age header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.age.1">3.2</a>, <a class="iref" href="#rfc.iref.a.2"><b>4.1</b></a>, <a class="iref" href="#rfc.xref.header.age.2">6.1</a></li>
<li class="indline1">max-age&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.6"><b>4.2.1</b></a>, <a class="iref" href="#rfc.iref.c.17"><b>4.2.2</b></a></li>
<li class="indline1">max-stale&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.7"><b>4.2.1</b></a></li>
<li class="indline1">min-fresh&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.8"><b>4.2.1</b></a></li>
<li class="indline1">must-revalidate&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.15"><b>4.2.2</b></a></li>
<li class="indline1">no-cache&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.4"><b>4.2.1</b></a>, <a class="iref" href="#rfc.iref.c.13"><b>4.2.2</b></a></li>
<li class="indline1">no-store&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.5"><b>4.2.1</b></a>, <a class="iref" href="#rfc.iref.c.14"><b>4.2.2</b></a></li>
<li class="indline1">no-transform&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.9"><b>4.2.1</b></a>, <a class="iref" href="#rfc.iref.c.19"><b>4.2.2</b></a></li>
<li class="indline1">only-if-cached&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.10"><b>4.2.1</b></a></li>
<li class="indline1">private&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.12"><b>4.2.2</b></a></li>
<li class="indline1">proxy-revalidate&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.16"><b>4.2.2</b></a></li>
<li class="indline1">public&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.11"><b>4.2.2</b></a></li>
<li class="indline1">s-maxage&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.18"><b>4.2.2</b></a></li>
<li class="indline1">Cache-Control header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.cache-control.1">3.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.2">3.2</a>, <a class="iref" href="#rfc.xref.header.cache-control.3">3.2</a>, <a class="iref" href="#rfc.xref.header.cache-control.4">3.2</a>, <a class="iref" href="#rfc.iref.c.3"><b>4.2</b></a>, <a class="iref" href="#rfc.xref.header.cache-control.5">6.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.6">A.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.7">A.1</a></li>
<li class="indline1">Expires header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.expires.1">3.3</a>, <a class="iref" href="#rfc.xref.header.expires.2">3.3.1</a>, <a class="iref" href="#rfc.iref.e.2"><b>4.3</b></a>, <a class="iref" href="#rfc.xref.header.expires.3">6.1</a></li>
<li class="indline1"><tt>Age</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.1"><b>4.1</b></a></li>
<li class="indline1"><tt>age-value</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.2"><b>4.1</b></a></li>
<li class="indline1"><tt>Cache-Control</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.4"><b>4.2</b></a></li>
<li class="indline1"><tt>cache-directive</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.5"><b>4.2</b></a></li>
<li class="indline1"><tt>cache-extension</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.6"><b>4.2</b></a></li>
<li class="indline1"><tt>cache-request-directive</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.7"><b>4.2.1</b></a></li>
<li class="indline1"><tt>cache-response-directive</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.8"><b>4.2.2</b></a></li>
<li class="indline1"><tt>delta-seconds</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.3"><b>4.1</b></a></li>
<li class="indline1"><tt>Expires</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.9"><b>4.3</b></a></li>
<li class="indline1"><tt>extension-pragma</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.12"><b>4.4</b></a></li>
<li class="indline1"><tt>Pragma</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.10"><b>4.4</b></a></li>
<li class="indline1"><tt>pragma-directive</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.11"><b>4.4</b></a></li>
<li class="indline1"><tt>Vary</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.13"><b>4.5</b></a></li>
<li class="indline1"><tt>warn-agent</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.17"><b>4.6</b></a></li>
<li class="indline1"><tt>warn-code</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.16"><b>4.6</b></a></li>
<li class="indline1"><tt>warn-date</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.19"><b>4.6</b></a></li>
<li class="indline1"><tt>warn-text</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.18"><b>4.6</b></a></li>
<li class="indline1"><tt>Warning</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.14"><b>4.6</b></a></li>
<li class="indline1"><tt>warning-value</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.15"><b>4.6</b></a></li>
<li class="indline1">Age&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.age.1">3.2</a>, <a class="iref" href="#rfc.iref.h.2"><b>4.1</b></a>, <a class="iref" href="#rfc.xref.header.age.2">6.1</a></li>
<li class="indline1">Cache-Control&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.cache-control.1">3.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.2">3.2</a>, <a class="iref" href="#rfc.xref.header.cache-control.3">3.2</a>, <a class="iref" href="#rfc.xref.header.cache-control.4">3.2</a>, <a class="iref" href="#rfc.iref.h.3"><b>4.2</b></a>, <a class="iref" href="#rfc.xref.header.cache-control.5">6.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.6">A.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.7">A.1</a></li>
<li class="indline1">Expires&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.expires.1">3.3</a>, <a class="iref" href="#rfc.xref.header.expires.2">3.3.1</a>, <a class="iref" href="#rfc.iref.h.4"><b>4.3</b></a>, <a class="iref" href="#rfc.xref.header.expires.3">6.1</a></li>
<li class="indline1">Pragma&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.pragma.1">3.2</a>, <a class="iref" href="#rfc.xref.header.pragma.2">4.2</a>, <a class="iref" href="#rfc.iref.h.5"><b>4.4</b></a>, <a class="iref" href="#rfc.xref.header.pragma.3">6.1</a></li>
<li class="indline1">Vary&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.vary.1">3.6</a>, <a class="iref" href="#rfc.iref.h.6"><b>4.5</b></a>, <a class="iref" href="#rfc.xref.header.vary.2">6.1</a></li>
<li class="indline1">Warning&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.warning.1">3.3.3</a>, <a class="iref" href="#rfc.xref.header.warning.2">3.7</a>, <a class="iref" href="#rfc.iref.h.7"><b>4.6</b></a>, <a class="iref" href="#rfc.xref.header.warning.3">6.1</a>, <a class="iref" href="#rfc.xref.header.warning.4">A.1</a></li>
<li class="indline1"><em>ISO-8859-1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.ISO-8859-1.1">4.6</a>, <a class="iref" href="#ISO-8859-1"><b>9.1</b></a></li>
<li class="indline1">Cache Directive&nbsp;&nbsp;<a class="iref" href="#rfc.iref.m.1"><b>4.2.1</b></a>, <a class="iref" href="#rfc.iref.m.5"><b>4.2.2</b></a></li>
<li class="indline1">Cache Directive&nbsp;&nbsp;<a class="iref" href="#rfc.iref.m.2"><b>4.2.1</b></a></li>
<li class="indline1">Cache Directive&nbsp;&nbsp;<a class="iref" href="#rfc.iref.m.3"><b>4.2.1</b></a></li>
<li class="indline1">Cache Directive&nbsp;&nbsp;<a class="iref" href="#rfc.iref.m.4"><b>4.2.2</b></a></li>
<li class="indline1">Cache Directive&nbsp;&nbsp;<a class="iref" href="#rfc.iref.n.1"><b>4.2.1</b></a>, <a class="iref" href="#rfc.iref.n.4"><b>4.2.2</b></a></li>
<li class="indline1">Cache Directive&nbsp;&nbsp;<a class="iref" href="#rfc.iref.n.2"><b>4.2.1</b></a>, <a class="iref" href="#rfc.iref.n.5"><b>4.2.2</b></a></li>
<li class="indline1">Cache Directive&nbsp;&nbsp;<a class="iref" href="#rfc.iref.n.3"><b>4.2.1</b></a>, <a class="iref" href="#rfc.iref.n.6"><b>4.2.2</b></a></li>
<li class="indline1">Cache Directive&nbsp;&nbsp;<a class="iref" href="#rfc.iref.o.1"><b>4.2.1</b></a></li>
<li class="indline1"><em>Part1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.1">2</a>, <a class="iref" href="#rfc.xref.Part1.2">2</a>, <a class="iref" href="#rfc.xref.Part1.3">2</a>, <a class="iref" href="#rfc.xref.Part1.4">2</a>, <a class="iref" href="#rfc.xref.Part1.5">2</a>, <a class="iref" href="#rfc.xref.Part1.6">2</a>, <a class="iref" href="#rfc.xref.Part1.7">2</a>, <a class="iref" href="#rfc.xref.Part1.8">2</a>, <a class="iref" href="#rfc.xref.Part1.9">2</a>, <a class="iref" href="#rfc.xref.Part1.10">2</a>, <a class="iref" href="#rfc.xref.Part1.11">2</a>, <a class="iref" href="#rfc.xref.Part1.12">2</a>, <a class="iref" href="#rfc.xref.Part1.13">3.3.2</a>, <a class="iref" href="#rfc.xref.Part1.14">3.6</a>, <a class="iref" href="#rfc.xref.Part1.15">4.3</a>, <a class="iref" href="#Part1"><b>9.1</b></a>, <a class="iref" href="#rfc.xref.Part1.16">A.1</a><ul class="ind">
<li class="indline1"><em>Section 2.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.10">2</a>, <a class="iref" href="#rfc.xref.Part1.12">2</a></li>
<li class="indline1"><em>Section 3.2.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.9">2</a>, <a class="iref" href="#rfc.xref.Part1.15">4.3</a></li>
<li class="indline1"><em>Section 4.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.8">2</a>, <a class="iref" href="#rfc.xref.Part1.14">3.6</a></li>
<li class="indline1"><em>Section 8.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.13">3.3.2</a></li>
<li class="indline1"><em>Part2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.1">3.5</a>, <a class="iref" href="#Part2"><b>9.1</b></a><ul class="ind">
<li class="indline1"><em>Section 7.1.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.1">3.5</a></li>
<li class="indline1"><em>Part3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.1">3.6</a>, <a class="iref" href="#Part3"><b>9.1</b></a>, <a class="iref" href="#rfc.xref.Part3.2">A.1</a><ul class="ind">
<li class="indline1"><em>Section 4.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.1">3.6</a></li>
<li class="indline1"><em>Part4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part4.1">3.3.1.1</a>, <a class="iref" href="#rfc.xref.Part4.2">3.4</a>, <a class="iref" href="#Part4"><b>9.1</b></a><ul class="ind">
<li class="indline1"><em>Section 6.6</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part4.1">3.3.1.1</a></li>
<li class="indline1"><em>Part5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part5.1">3.1.1</a>, <a class="iref" href="#rfc.xref.Part5.2">3.1.1</a>, <a class="iref" href="#rfc.xref.Part5.3">3.7</a>, <a class="iref" href="#Part5"><b>9.1</b></a>, <a class="iref" href="#rfc.xref.Part5.4">A.1</a><ul class="ind">
<li class="indline1"><em>Section 4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part5.2">3.1.1</a>, <a class="iref" href="#rfc.xref.Part5.3">3.7</a></li>
<li class="indline1"><em>Part7</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part7.1">3.2</a>, <a class="iref" href="#rfc.xref.Part7.2">4.2.2</a>, <a class="iref" href="#Part7"><b>9.1</b></a><ul class="ind">
<li class="indline1"><em>Section 3.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part7.1">3.2</a>, <a class="iref" href="#rfc.xref.Part7.2">4.2.2</a></li>
<li class="indline1">Pragma header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.pragma.1">3.2</a>, <a class="iref" href="#rfc.xref.header.pragma.2">4.2</a>, <a class="iref" href="#rfc.iref.p.4"><b>4.4</b></a>, <a class="iref" href="#rfc.xref.header.pragma.3">6.1</a></li>
<li class="indline1">Cache Directive&nbsp;&nbsp;<a class="iref" href="#rfc.iref.p.2"><b>4.2.2</b></a></li>
<li class="indline1">Cache Directive&nbsp;&nbsp;<a class="iref" href="#rfc.iref.p.3"><b>4.2.2</b></a></li>
<li class="indline1">Cache Directive&nbsp;&nbsp;<a class="iref" href="#rfc.iref.p.1"><b>4.2.2</b></a></li>
<li class="indline1"><em>RFC1305</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1305.1">3.3.2</a>, <a class="iref" href="#RFC1305"><b>9.2</b></a></li>
<li class="indline1"><em>RFC2047</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2047.1">4.6</a>, <a class="iref" href="#RFC2047"><b>9.1</b></a></li>
<li class="indline1"><em>RFC2119</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2119.1">1.3</a>, <a class="iref" href="#RFC2119"><b>9.1</b></a></li>
<li class="indline1"><em>RFC2616</em>&nbsp;&nbsp;<a class="iref" href="#RFC2616"><b>9.2</b></a>, <a class="iref" href="#rfc.xref.RFC2616.1">B.1</a></li>
<li class="indline1">Cache Directive&nbsp;&nbsp;<a class="iref" href="#rfc.iref.s.2"><b>4.2.2</b></a></li>
<li class="indline1">Vary header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.vary.1">3.6</a>, <a class="iref" href="#rfc.iref.v.3"><b>4.5</b></a>, <a class="iref" href="#rfc.xref.header.vary.2">6.1</a></li>
<li class="indline1">Warning header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.warning.1">3.3.3</a>, <a class="iref" href="#rfc.xref.header.warning.2">3.7</a>, <a class="iref" href="#rfc.iref.w.1"><b>4.6</b></a>, <a class="iref" href="#rfc.xref.header.warning.3">6.1</a>, <a class="iref" href="#rfc.xref.header.warning.4">A.1</a></li>