source: draft-ietf-httpbis/latest/p6-cache.xml

Last change on this file was 2724, checked in by julian.reschke@…, 5 years ago

revert changes for auth48 boilerplate checks (#553)

  • Property svn:eol-style set to native
  • Property svn:mime-type set to text/xml
File size: 111.8 KB
Line 
1<?xml version="1.0" encoding="utf-8"?>
2<?xml-stylesheet type='text/xsl' href='../myxml2rfc.xslt'?>
3<!DOCTYPE rfc [
4  <!ENTITY MAY "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MAY</bcp14>">
5  <!ENTITY MUST "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MUST</bcp14>">
6  <!ENTITY MUST-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MUST NOT</bcp14>">
7  <!ENTITY OPTIONAL "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>OPTIONAL</bcp14>">
8  <!ENTITY RECOMMENDED "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>RECOMMENDED</bcp14>">
9  <!ENTITY REQUIRED "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>REQUIRED</bcp14>">
10  <!ENTITY SHALL "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHALL</bcp14>">
11  <!ENTITY SHALL-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHALL NOT</bcp14>">
12  <!ENTITY SHOULD "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD</bcp14>">
13  <!ENTITY SHOULD-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD NOT</bcp14>">
14  <!ENTITY ID-VERSION "latest">
15  <!ENTITY ID-MONTH "June">
16  <!ENTITY ID-YEAR "2014">
17  <!ENTITY mdash "&#8212;">
18  <!ENTITY Note "<x:h xmlns:x='http://purl.org/net/xml2rfc/ext'>Note:</x:h>">
19  <!ENTITY architecture                "<xref target='RFC7230' x:rel='#architecture' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
20  <!ENTITY conformance                 "<xref target='RFC7230' x:rel='#conformance' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
21  <!ENTITY notation                    "<xref target='RFC7230' x:rel='#notation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
22  <!ENTITY abnf-extension              "<xref target='RFC7230' x:rel='#abnf.extension' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
23  <!ENTITY acks                        "<xref target='RFC7230' x:rel='#acks' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
24  <!ENTITY whitespace                  "<xref target='RFC7230' x:rel='#whitespace' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
25  <!ENTITY field-components            "<xref target='RFC7230' x:rel='#field.components' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
26  <!ENTITY uri                         "<xref target='RFC7230' x:rel='#uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
27  <!ENTITY effective-request-uri       "<xref target='RFC7230' x:rel='#effective.request.uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
28  <!ENTITY messaging                   "<xref target='RFC7230' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
29  <!ENTITY semantics                   "<xref target='RFC7231' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
30  <!ENTITY conditional                 "<xref target='RFC7232' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
31  <!ENTITY conditional-precedence      "<xref target='RFC7232' x:rel='#precedence' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
32  <!ENTITY partial                     "<xref target='RFC7233' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
33  <!ENTITY combining-byte-ranges       "<xref target='RFC7233' x:rel='#combining.byte.ranges' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
34  <!ENTITY http-date                   "<xref target='RFC7231' x:rel='#http.date' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
35  <!ENTITY header-authorization        "<xref target='RFC7235' x:rel='#header.authorization' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
36  <!ENTITY header-connection           "<xref target='RFC7230' x:rel='#header.connection' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
37  <!ENTITY header-date                 "<xref target='RFC7231' x:rel='#header.date' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
38  <!ENTITY header-etag                 "<xref target='RFC7232' x:rel='#header.etag' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
39  <!ENTITY header-if-match             "<xref target='RFC7232' x:rel='#header.if-match' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
40  <!ENTITY header-if-none-match        "<xref target='RFC7232' x:rel='#header.if-none-match' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
41  <!ENTITY header-if-modified-since    "<xref target='RFC7232' x:rel='#header.if-modified-since' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
42  <!ENTITY header-if-unmodified-since  "<xref target='RFC7232' x:rel='#header.if-unmodified-since' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
43  <!ENTITY header-if-range             "<xref target='RFC7233' x:rel='#header.if-range' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
44  <!ENTITY header-last-modified        "<xref target='RFC7232' x:rel='#header.last-modified' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
45  <!ENTITY header-vary                 "<xref target='RFC7231' x:rel='#header.vary' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
46  <!ENTITY header-via                  "<xref target='RFC7230' x:rel='#header.via' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
47  <!ENTITY header-fields               "<xref target='RFC7230' x:rel='#header.fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
48  <!ENTITY GET                         "<xref target='RFC7231' x:rel='#GET' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
49  <!ENTITY safe-methods                "<xref target='RFC7231' x:rel='#safe.methods' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
50  <!ENTITY entity-tags                 "<xref target='RFC7232' x:rel='#header.etag' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
51  <!ENTITY weak-and-strong             "<xref target='RFC7232' x:rel='#weak.and.strong.validators' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
52  <!ENTITY lastmod-comparison          "<xref target='RFC7232' x:rel='#lastmod.comparison' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
53  <!ENTITY status-codes                "<xref target='RFC7231' x:rel='#status.codes' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
54  <!ENTITY status-overview             "<xref target='RFC7231' x:rel='#overview.of.status.codes' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
55  <!ENTITY status.2xx                  "<xref target='RFC7231' x:rel='#status.2xx' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
56  <!ENTITY transformations             "<xref target='RFC7230' x:rel='#message.transformations' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
57  <!ENTITY body.length                 "<xref target='RFC7230' x:rel='#message.body.length' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
58]>
59<?rfc toc="yes" ?>
60<?rfc symrefs="yes" ?>
61<?rfc sortrefs="yes" ?>
62<?rfc compact="yes"?>
63<?rfc subcompact="no" ?>
64<?rfc linkmailto="no" ?>
65<?rfc editing="no" ?>
66<?rfc comments="yes"?>
67<?rfc inline="yes"?>
68<?rfc rfcedstyle="yes"?>
69<?rfc-ext allow-markup-in-artwork="yes" ?>
70<?rfc-ext include-references-in-index="yes" ?>
71<rfc category="std" docName="draft-ietf-httpbis-p6-cache-&ID-VERSION;" ipr="pre5378Trust200902"
72  obsoletes="2616" x:maturity-level="proposed" xmlns:x="http://purl.org/net/xml2rfc/ext">
73<x:link rel="Alternate" title="RFC7234" href="http://svn.tools.ietf.org/svn/wg/httpbis/specs/rfc7234.html"/>
74<x:link rel="prev" basename="p5-range"/>
75<x:link rel="next" basename="p7-auth"/>
76<x:feedback template="mailto:ietf-http-wg@w3.org?subject={docname},%20%22{section}%22&amp;body=&lt;{ref}&gt;:"/>
77<front>
78
79  <title abbrev="HTTP/1.1 Caching">Hypertext Transfer Protocol (HTTP/1.1): Caching</title>
80
81  <author fullname="Roy T. Fielding" initials="R." role="editor" surname="Fielding">
82    <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
83    <address>
84      <postal>
85        <street>345 Park Ave</street>
86        <city>San Jose</city>
87        <region>CA</region>
88        <code>95110</code>
89        <country>USA</country>
90      </postal>
91      <email>fielding@gbiv.com</email>
92      <uri>http://roy.gbiv.com/</uri>
93    </address>
94  </author>
95
96  <author fullname="Mark Nottingham" initials="M." role="editor" surname="Nottingham">
97    <organization>Akamai</organization>
98    <address>
99      <email>mnot@mnot.net</email>
100      <uri>http://www.mnot.net/</uri>
101    </address>
102  </author>
103
104  <author fullname="Julian F. Reschke" initials="J. F." role="editor" surname="Reschke">
105    <organization abbrev="greenbytes">greenbytes GmbH</organization>
106    <address>
107      <postal>
108        <street>Hafenweg 16</street>
109        <city>Muenster</city><region>NW</region><code>48155</code>
110        <country>Germany</country>
111      </postal>
112      <email>julian.reschke@greenbytes.de</email>
113      <uri>http://greenbytes.de/tech/webdav/</uri>
114    </address>
115  </author>
116
117  <date month="&ID-MONTH;" year="&ID-YEAR;" />
118
119  <area>Applications</area>
120  <workgroup>HTTPbis</workgroup>
121
122  <keyword>Hypertext Transfer Protocol</keyword>
123  <keyword>HTTP</keyword>
124  <keyword>HTTP Caching</keyword>
125
126<abstract>
127<t>
128   The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for
129   distributed, collaborative, hypertext information systems. This document
130   defines HTTP caches and the associated header fields
131   that control cache behavior or indicate cacheable response messages.
132</t>
133</abstract>
134
135<note title="Editorial Note (To be removed by RFC Editor)">
136  <t>
137    Discussion of this draft takes place on the HTTPBIS working group
138    mailing list (ietf-http-wg@w3.org), which is archived at
139    <eref target="http://lists.w3.org/Archives/Public/ietf-http-wg/"/>.
140  </t>
141  <t>
142    The current issues list is at
143    <eref target="http://tools.ietf.org/wg/httpbis/trac/report/3"/> and related
144    documents (including fancy diffs) can be found at
145    <eref target="http://tools.ietf.org/wg/httpbis/"/>.
146  </t>
147  <t>
148    <spanx>This is a temporary document for the purpose of tracking the editorial changes made during the AUTH48 (RFC publication) phase.</spanx>
149  </t>
150</note>
151
152   </front>
153   <middle>
154
155<section anchor="caching" title="Introduction">
156<t>
157   HTTP is typically used for distributed information systems, where
158   performance can be improved by the use of response caches. This document
159   defines aspects of HTTP/1.1 related to caching and reusing response
160   messages.
161</t>
162
163<iref item="cache" />
164<t>
165   An HTTP <x:dfn>cache</x:dfn> is a local store of response messages and the
166   subsystem that controls storage, retrieval, and deletion of messages in it.
167   A cache stores cacheable responses in order to reduce the response time and
168   network bandwidth consumption on future, equivalent requests. Any client or
169   server &MAY; employ a cache, though a cache cannot be used by a server that
170   is acting as a tunnel.
171</t>
172<iref item="shared cache" />
173<iref item="private cache" />
174<t anchor="shared.and.private.caches">
175   A <x:dfn>shared cache</x:dfn> is a cache that stores responses to be reused
176   by more than one user; shared caches are usually (but not always) deployed
177   as a part of an intermediary. A <x:dfn>private cache</x:dfn>, in contrast,
178   is dedicated to a single user; often, they are deployed as a component of
179   a user agent.
180</t>
181<t>
182   The goal of caching in HTTP/1.1 is to significantly improve performance
183   by reusing a prior response message to satisfy a current request.
184   A stored response is considered "fresh", as defined in
185   <xref target="expiration.model" />, if the response can be reused without
186   "validation" (checking with the origin server to see if the cached response
187   remains valid for this request).  A fresh response can therefore
188   reduce both latency and network overhead each time it is reused.
189   When a cached response is not fresh, it might still be reusable if it can
190   be freshened by validation (<xref target="validation.model" />) or if the
191   origin is unavailable (<xref target="serving.stale.responses" />).
192</t>
193
194<section title="Conformance and Error Handling" anchor="conformance">
195<t>
196   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
197   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
198   document are to be interpreted as described in <xref target="RFC2119"/>.
199</t>
200<t>
201   Conformance criteria and considerations regarding error handling
202   are defined in &conformance;.
203</t>
204</section>
205
206<section title="Syntax Notation" anchor="notation">
207<t>
208   This specification uses the Augmented Backus-Naur Form (ABNF) notation of
209   <xref target="RFC5234"/> with a list extension, defined in
210   &abnf-extension;, that allows for compact definition of
211   comma-separated lists using a '#' operator (similar to how the '*' operator
212   indicates repetition).
213   <xref target="imported.abnf"/> describes rules imported from
214   other documents.
215   <xref target="collected.abnf"/> shows the collected grammar with all list
216   operators expanded to standard ABNF notation.
217</t>
218
219<section title="Delta Seconds" anchor="delta-seconds">
220<t>
221   The delta-seconds rule specifies a non-negative integer, representing time
222   in seconds.
223</t>
224<figure><artwork type="abnf2616"><iref item="Grammar" primary="true" subitem="delta-seconds" />
225  <x:ref>delta-seconds</x:ref>  = 1*<x:ref>DIGIT</x:ref>
226</artwork></figure>
227<t>
228   A recipient parsing a delta-seconds value and converting it to binary form
229   ought to use an arithmetic type of at least 31 bits of non-negative integer
230   range.
231   If a cache receives a delta-seconds value greater than the greatest integer
232   it can represent, or if any of its subsequent calculations overflows,
233   the cache &MUST; consider the value to be either 2147483648
234   (2<x:sup>31</x:sup>) or the greatest positive integer it can conveniently
235   represent.
236</t>
237<x:note>
238   <t>
239       &Note; The value 2147483648 is here for historical reasons, effectively
240       represents infinity (over 68 years), and does not need to be stored in
241       binary form; an implementation could produce it as a canned string if
242       any overflow occurs, even if the calculations are performed with an
243       arithmetic type incapable of directly representing that number.
244       What matters here is that an overflow be detected and not treated as a
245       negative value in later calculations.
246   </t>
247</x:note>
248</section>
249
250</section>
251</section>
252
253<section anchor="caching.overview" title="Overview of Cache Operation">
254<iref item="cache entry" />
255<iref item="cache key" />
256<t>
257   Proper cache operation preserves the semantics of HTTP transfers
258   (&semantics;) while eliminating the transfer of information already held
259   in the cache.  Although caching is an entirely &OPTIONAL; feature of HTTP,
260   it can be assumed that reusing a cached response is desirable and that such
261   reuse is the default behavior when no requirement or local
262   configuration prevents it.  Therefore, HTTP cache requirements are focused
263   on preventing a cache from either storing a non-reusable response or
264   reusing a stored response inappropriately, rather than mandating that
265   caches always store and reuse particular responses.
266</t>
267<t>
268   Each <x:dfn>cache entry</x:dfn> consists of a cache key and one or more
269   HTTP responses corresponding to prior requests that used the same key. The
270   most common form of cache entry is a successful result of a retrieval
271   request: i.e., a <x:ref>200 (OK)</x:ref> response to a GET request, which
272   contains a representation of the resource identified by the request target
273   (&GET;). However, it is also possible to cache permanent redirects,
274   negative results (e.g., <x:ref>404 (Not Found)</x:ref>),
275   incomplete results (e.g., <x:ref>206 (Partial Content)</x:ref>), and
276   responses to methods other than GET if the method's definition allows such
277   caching and defines something suitable for use as a cache key.
278</t>
279<iref item="cache key" />
280<t>
281   The primary <x:dfn>cache key</x:dfn> consists of the request method and
282   target URI.  However, since HTTP caches in common use today are typically
283   limited to caching responses to GET, many caches simply decline
284   other methods and use only the URI as the primary cache key.
285</t>
286<t>
287   If a request target is subject to content negotiation, its cache entry
288   might consist of multiple stored responses, each differentiated by a
289   secondary key for the values of the original request's selecting header
290   fields (<xref target="caching.negotiated.responses"/>).
291</t>
292</section>
293
294<section anchor="response.cacheability" title="Storing Responses in Caches">
295<t>
296   A cache &MUST-NOT; store a response to any request, unless:
297   <list style="symbols">
298      <t>The request method is understood by the cache and defined as being
299      cacheable, and</t>
300      <t>the response status code is understood by the cache, and</t>
301      <t>the "no-store" cache directive (see <xref
302      target="header.cache-control" />) does not appear in request or response
303      header fields, and</t>
304      <t>the "private" response directive (see <xref
305      target="cache-response-directive.private" />) does not appear in the
306      response, if the cache is shared, and</t>
307      <t>the <x:ref>Authorization</x:ref> header field (see
308      &header-authorization;) does not appear in the request, if the cache is
309      shared, unless the response explicitly allows it (see <xref
310      target="caching.authenticated.responses" />), and</t>
311      <t>the response either:
312         <list style="symbols">
313            <t>contains an <x:ref>Expires</x:ref> header field (see
314            <xref target="header.expires"/>), or</t>
315            <t>contains a max-age response directive (see <xref
316            target="cache-response-directive.max-age" />), or</t>
317            <t>contains a s-maxage response directive (see <xref
318            target="cache-response-directive.s-maxage" />) and the cache is
319            shared, or</t>
320            <t>contains a Cache Control Extension (see <xref
321            target="cache.control.extensions" />) that allows it to be cached,
322            or</t>
323            <t>has a status code that is defined as cacheable by default
324            (see <xref target="heuristic.freshness" />), or</t>
325            <t>contains a public response directive (see <xref
326            target="cache-response-directive.public"/>).</t>
327         </list>
328      </t>
329   </list>
330</t>
331<t>
332   Note that any of the requirements listed above can be overridden by a
333   cache-control extension; see <xref target="cache.control.extensions" />.
334</t>
335<t>
336   In this context, a cache has "understood" a request method or a response
337   status code if it recognizes it and implements all specified
338   caching-related behavior.
339</t>
340<t>
341   Note that, in normal operation, some caches will not store a response that
342   has neither a cache validator nor an explicit expiration time, as such
343   responses are not usually useful to store. However, caches are not
344   prohibited from storing such responses.
345</t>
346
347<section anchor="incomplete.responses" title="Storing Incomplete Responses">
348<t>
349   A response message is considered complete when all of the octets indicated
350   by the message framing (&messaging;) are received prior to the connection
351   being closed. If the request method is GET, the response status code is
352   <x:ref>200 (OK)</x:ref>, and the entire response header section has been received, a
353   cache &MAY; store an incomplete response message body if the cache entry is
354   recorded as incomplete. Likewise, a <x:ref>206 (Partial Content)</x:ref>
355   response &MAY; be stored as if it were an incomplete <x:ref>200
356   (OK)</x:ref> cache entry. However, a cache &MUST-NOT; store incomplete or
357   partial-content responses if it does not support the <x:ref>Range</x:ref>
358   and <x:ref>Content-Range</x:ref> header fields or if it does not understand
359   the range units used in those fields.
360</t>
361<t>
362   A cache &MAY; complete a stored incomplete response by making a subsequent
363   range request (&partial;) and combining the successful response with the
364   stored entry, as defined in <xref target="combining.responses"/>. A cache
365   &MUST-NOT; use an incomplete response to answer requests unless the
366   response has been made complete or the request is partial and specifies a
367   range that is wholly within the incomplete response. A cache &MUST-NOT;
368   send a partial response to a client without explicitly marking it as such
369   using the <x:ref>206 (Partial Content)</x:ref> status code.
370</t>
371</section>
372
373
374<section anchor="caching.authenticated.responses" 
375   title="Storing Responses to Authenticated Requests">
376<t>
377   A shared cache &MUST-NOT; use a cached response to a request with an
378   <x:ref>Authorization</x:ref> header field (&header-authorization;) to
379   satisfy any subsequent request unless a cache directive that allows such
380   responses to be stored is present in the response.
381</t>
382<t>
383   In this specification, the following <x:ref>Cache-Control</x:ref> response
384   directives (<xref target="cache-response-directive"/>) have such an effect:
385   must-revalidate, public, and s-maxage.
386</t>
387<t>
388   Note that cached responses that contain the "must-revalidate" and/or
389   "s-maxage" response directives are not allowed to be served stale (<xref
390   target="serving.stale.responses"/>) by shared caches. In particular, a
391   response with either "max-age=0, must-revalidate" or "s-maxage=0" cannot be
392   used to satisfy a subsequent request without revalidating it on the origin
393   server.
394</t>
395</section>
396
397<section anchor="combining.responses" title="Combining Partial Content">
398<t>
399   A response might transfer only a partial representation if the
400   connection closed prematurely or if the request used one or more Range
401   specifiers (&partial;).  After several such transfers, a cache might have
402   received several ranges of the same representation.  A cache &MAY; combine
403   these ranges into a single stored response, and reuse that response to
404   satisfy later requests, if they all share the same strong validator and
405   the cache complies with the client requirements in &combining-byte-ranges;.
406</t>
407<t>
408   When combining the new response with one or more stored responses, a
409   cache &MUST;:
410   <list style="symbols">
411      <t>delete any <x:ref>Warning</x:ref> header fields in the stored response
412         with warn-code 1xx (see <xref target="header.warning" />);</t>
413      <t>retain any <x:ref>Warning</x:ref> header fields in the stored response
414         with warn-code 2xx; and,</t>
415      <t>use other header fields provided in the new response, aside
416         from <x:ref>Content-Range</x:ref>, to replace all instances of the
417         corresponding header fields in the stored response.</t>
418   </list>
419</t>
420</section>
421
422</section>
423
424
425<section anchor="constructing.responses.from.caches" 
426   title="Constructing Responses from Caches">
427<t>
428   When presented with a request, a cache &MUST-NOT; reuse a stored response,
429   unless:
430   <list style="symbols">
431      <t>The presented effective request URI (&effective-request-uri;) and
432      that of the stored response match, and</t>
433      <t>the request method associated with the stored response allows it to
434      be used for the presented request, and</t>
435      <t>selecting header fields nominated by the stored response (if any)
436      match those presented (see <xref target="caching.negotiated.responses"
437      />), and</t>
438      <t>the presented request does not contain the no-cache pragma (<xref
439      target="header.pragma"/>), nor the no-cache cache directive (<xref
440      target="cache-request-directive"/>), unless the stored response is
441      successfully validated (<xref target="validation.model"/>), and</t>
442      <t>the stored response does not contain the no-cache cache directive
443      (<xref target="cache-response-directive.no-cache"/>), unless it is
444      successfully validated (<xref target="validation.model"/>), and</t>
445      <t>the stored response is either:
446         <list style="symbols">
447            <t>fresh (see <xref target="expiration.model" />), or</t>
448            <t>allowed to be served stale (see <xref
449            target="serving.stale.responses" />), or</t>
450            <t>successfully validated (see <xref target="validation.model"
451            />).</t>
452         </list>
453      </t>
454  </list>
455</t>
456<t>
457   Note that any of the requirements listed above can be overridden by a
458   cache-control extension; see <xref target="cache.control.extensions" />.
459</t>
460<t>
461   When a stored response is used to satisfy a request without validation, a
462   cache &MUST; generate an <x:ref>Age</x:ref> header field (<xref
463   target="header.age"/>), replacing any present in the response with a value
464   equal to the stored response's current_age; see <xref
465   target="age.calculations" />.
466</t>
467<t>
468   A cache &MUST; write through requests with methods that are unsafe
469   (&safe-methods;) to the origin server; i.e., a cache is not allowed to
470   generate a reply to such a request before having forwarded the request and
471   having received a corresponding response.
472</t>
473<t>
474   Also, note that unsafe requests might invalidate already-stored responses;
475   see <xref target="invalidation" />.
476</t>
477<t>
478   When more than one suitable response is stored, a cache &MUST; use the
479   most recent response (as determined by the <x:ref>Date</x:ref> header
480   field). It can also forward the request with "Cache-Control: max-age=0" or
481   "Cache-Control: no-cache" to disambiguate which response to use.
482</t>
483<t>
484   A cache that does not have a clock available &MUST-NOT; use stored
485   responses without revalidating them upon every use.
486</t>
487
488<section anchor="caching.negotiated.responses" 
489   title="Calculating Secondary Keys with Vary">
490<t>
491   When a cache receives a request that can be satisfied by a stored response
492   that has a <x:ref>Vary</x:ref> header field (&header-vary;),
493   it &MUST-NOT; use that response unless all of the selecting header fields
494   nominated by the Vary header field match in both the original request
495   (i.e., that associated with the stored response), and the presented
496   request.
497</t>
498<t>
499   The selecting header fields from two requests are defined to match if and
500   only if those in the first request can be transformed to those in the
501   second request by applying any of the following:
502   <list style="symbols">
503      <t>
504         adding or removing whitespace, where allowed in the header field's
505         syntax
506      </t>
507      <t>
508         combining multiple header fields with the same field name
509         (see &header-fields;)
510      </t>
511      <t>
512         normalizing both header field values in a way that is known to have
513         identical semantics, according to the header field's specification
514         (e.g., reordering field values when order is not significant;
515         case-normalization, where values are defined to be case-insensitive)
516      </t>
517  </list>
518</t>
519<t>
520   If (after any normalization that might take place) a header field is absent
521   from a request, it can only match another request if it is also absent
522   there.
523</t>
524<t>
525   A <x:ref>Vary</x:ref> header field-value of "*" always fails to match.
526</t>
527<t>
528   The stored response with matching selecting header fields is known as the
529   selected response.
530</t>
531<t>
532   If multiple selected responses are available (potentially including
533   responses without a Vary header field), the cache will need to choose one to use.
534   When a selecting header field has a known mechanism for doing so (e.g., qvalues on
535   <x:ref>Accept</x:ref> and similar request header fields), that mechanism &MAY; be
536   used to select preferred responses; of the remainder, the most recent
537   response (as determined by the <x:ref>Date</x:ref> header field) is used, as
538   per <xref target="constructing.responses.from.caches"/>.
539</t>
540<t>
541   If no selected response is available, the cache cannot satisfy the
542   presented request. Typically, it is forwarded to the origin server
543   in a (possibly conditional; see <xref target="validation.model"/>) request.
544</t>
545</section>
546
547<section anchor="expiration.model" title="Freshness">
548<iref item="fresh" />
549<iref item="stale" />
550<t>
551   A <x:dfn>fresh</x:dfn> response is one whose age has not yet exceeded its
552   freshness lifetime. Conversely, a <x:dfn>stale</x:dfn>
553   response is one where it has.
554</t>
555<iref item="freshness lifetime" />
556<iref item="explicit expiration time" />
557<iref item="heuristic expiration time" />
558<t>
559   A response's <x:dfn>freshness lifetime</x:dfn> is the length of time
560   between its generation by the origin server and its expiration time. An
561   <x:dfn>explicit expiration time</x:dfn> is the time at which the origin
562   server intends that a stored response can no longer be used by a cache
563   without further validation, whereas a <x:dfn>heuristic expiration
564   time</x:dfn> is assigned by a cache when no explicit expiration time is
565   available.
566</t>
567<iref item="age" />
568<t>
569   A response's <x:dfn>age</x:dfn> is the time that has passed since it was
570   generated by, or successfully validated with, the origin server. 
571</t>
572<t>
573   When a response is "fresh" in the cache, it can be used to satisfy
574   subsequent requests without contacting the origin server, thereby improving
575   efficiency.
576</t>
577<t>
578   The primary mechanism for determining freshness is for an origin server to
579   provide an explicit expiration time in the future, using either the
580   <x:ref>Expires</x:ref> header field (<xref target="header.expires" />) or
581   the max-age response directive (<xref
582   target="cache-response-directive.max-age" />). Generally, origin servers
583   will assign future explicit expiration times to responses in the belief
584   that the representation is not likely to change in a semantically
585   significant way before the expiration time is reached.
586</t>
587<t>
588   If an origin server wishes to force a cache to validate every request, it
589   can assign an explicit expiration time in the past to indicate that the
590   response is already stale. Compliant caches will normally validate a stale
591   cached response before reusing it for subsequent requests (see <xref
592   target="serving.stale.responses" />).
593</t>
594<t>
595   Since origin servers do not always provide explicit expiration times,
596   caches are also allowed to use a heuristic to determine an expiration time
597   under certain circumstances (see <xref target="heuristic.freshness"/>).
598</t>
599<figure>
600<preamble>
601  The calculation to determine if a response is fresh is:
602</preamble>
603<artwork type="code">
604   response_is_fresh = (freshness_lifetime &gt; current_age)
605</artwork>
606</figure>
607<t>
608   freshness_lifetime is defined in <xref
609   target="calculating.freshness.lifetime" />; current_age is defined in
610   <xref target="age.calculations" />.
611</t>
612<t>
613   Clients can send the max-age or min-fresh cache directives in a request to
614   constrain or relax freshness calculations for the corresponding response
615   (<xref target="cache-request-directive" />).
616</t>
617<t>
618   When calculating freshness, to avoid common problems in date parsing:
619</t>
620<t>
621  <list style="symbols">
622     <t>Although all date formats are specified to be case-sensitive,
623        a cache recipient &SHOULD; match day, week, and time-zone names
624        case-insensitively.</t>
625             
626     <t>If a cache recipient's internal implementation of time has less
627        resolution than the value of an HTTP-date, the recipient &MUST;
628        internally represent a parsed <x:ref>Expires</x:ref> date as the
629        nearest time equal to or earlier than the received value.</t>
630
631     <t>A cache recipient &MUST-NOT; allow local time zones to influence the
632        calculation or comparison of an age or expiration time.</t>
633
634     <t>A cache recipient &SHOULD; consider a date with a zone abbreviation
635        other than GMT or UTC to be invalid for calculating expiration.</t>
636  </list>
637</t>
638<t>
639   Note that freshness applies only to cache operation; it cannot be used to
640   force a user agent to refresh its display or reload a resource. See <xref
641   target="history.lists" /> for an explanation of the difference between
642   caches and history mechanisms.
643</t>
644
645<section anchor="calculating.freshness.lifetime" 
646   title="Calculating Freshness Lifetime">
647<t>
648   A cache can calculate the freshness lifetime (denoted as
649   freshness_lifetime) of a response by using the first match of the following:
650   <list style="symbols">
651      <t>If the cache is shared and the s-maxage response directive
652      (<xref target="cache-response-directive.s-maxage" />) is present, use its value,
653      or</t>
654      <t>If the max-age response directive (<xref
655      target="cache-response-directive.max-age" />) is present, use its value, or</t>
656      <t>If the <x:ref>Expires</x:ref> response header field
657      (<xref target="header.expires" />) is present, use its value minus the
658      value of the <x:ref>Date</x:ref> response header field, or</t>
659      <t>Otherwise, no explicit expiration time is present in the response. A
660      heuristic freshness lifetime might be applicable; see <xref
661      target="heuristic.freshness" />.</t>
662   </list>
663</t>
664<t>
665   Note that this calculation is not vulnerable to clock skew, since all of
666   the information comes from the origin server.
667</t>
668<t>
669   When there is more than one value present for a given directive (e.g., two
670   <x:ref>Expires</x:ref> header fields, multiple Cache-Control: max-age
671   directives), the directive's value is considered invalid. Caches are
672   encouraged to consider responses that have invalid freshness information to
673   be stale.
674</t>
675</section>
676
677<section anchor="heuristic.freshness" title="Calculating Heuristic Freshness">
678<t>
679   Since origin servers do not always provide explicit expiration times, a
680   cache &MAY; assign a heuristic expiration time when an explicit time is not
681   specified, employing algorithms that use other header field values (such as
682   the <x:ref>Last-Modified</x:ref> time) to estimate a plausible expiration
683   time. This specification does not provide specific algorithms, but does
684   impose worst-case constraints on their results.
685</t>
686<t>
687   A cache &MUST-NOT; use heuristics to determine freshness when an explicit
688   expiration time is present in the stored response. Because of the
689   requirements in <xref target="response.cacheability"/>, this means that,
690   effectively, heuristics can only be used on responses without explicit
691   freshness whose status codes are defined as cacheable by default (see
692   &status-overview;), and those responses without explicit freshness that have
693   been marked as explicitly cacheable (e.g., with a "public" response
694   directive).
695</t>
696<t>
697   If the response has a <x:ref>Last-Modified</x:ref> header field
698   (&header-last-modified;), caches are encouraged to use a heuristic
699   expiration value that is no more than some fraction of the interval since
700   that time. A typical setting of this fraction might be 10%.
701</t>
702<t>
703   When a heuristic is used to calculate freshness lifetime, a cache &SHOULD;
704   generate a <x:ref>Warning</x:ref> header field with a 113 warn-code (see
705   <xref target="warn.113"/>) in the response if its current_age is more than
706   24 hours and such a warning is not already present.
707</t>
708<x:note>
709   <t>
710      &Note; <xref target="RFC2616" x:fmt="of" x:sec="13.9"/> prohibited caches
711      from calculating heuristic freshness for URIs with query components
712      (i.e., those containing '?'). In practice, this has not been widely
713      implemented. Therefore, origin servers are encouraged to send explicit
714      directives (e.g., Cache-Control: no-cache) if they wish to preclude
715      caching.
716   </t>
717</x:note>
718</section>
719
720<section anchor="age.calculations" title="Calculating Age">
721<t>
722   The <x:ref>Age</x:ref> header field is used to convey an estimated
723   age of the response message when obtained from a cache. The Age field value
724   is the cache's estimate of the number of seconds since the response was
725   generated or validated by the origin server. In essence, the Age value is
726   the sum of the time that the response has been resident in each of the
727   caches along the path from the origin server, plus the amount of time it
728   has been in transit along network paths.
729</t>
730<t>
731   The following data is used for the age calculation:
732</t>
733<t>
734   <x:dfn>age_value</x:dfn>
735   <list>
736      <t>
737         The term "age_value" denotes the value of the <x:ref>Age</x:ref>
738         header field (<xref target="header.age"/>), in a form appropriate for
739         arithmetic operation; or 0, if not available.
740      </t>
741   </list>
742</t>
743<t>
744   <x:dfn>date_value</x:dfn>
745   <list>
746      <t>
747         The term "date_value" denotes the value of
748         the Date header field, in a form appropriate for arithmetic
749         operations. See &header-date; for the definition of the Date header
750         field, and for requirements regarding responses without it.
751      </t>
752   </list>
753</t>
754<t>
755   <x:dfn>now</x:dfn>
756   <list>
757      <t>
758         The term "now" means "the current value of the clock at the host
759         performing the calculation". A host ought to use NTP (<xref
760         target="RFC5905"/>) or some similar protocol to synchronize its
761         clocks to Coordinated Universal Time.
762      </t>
763   </list>
764</t>
765<t>
766   <x:dfn>request_time</x:dfn>
767   <list>
768      <t>
769         The current value of the clock at the host at the time the request
770         resulting in the stored response was made.
771      </t>
772   </list>
773</t>
774<t>
775   <x:dfn>response_time</x:dfn>
776   <list>
777      <t>
778         The current value of the clock at the host at the time the response
779         was received.
780      </t>
781   </list>
782</t>
783<t>
784   A response's age can be calculated in two entirely independent ways:
785   <list style="numbers">
786      <t>the "apparent_age": response_time minus date_value, if the local
787      clock is reasonably well synchronized to the origin server's clock. If
788      the result is negative, the result is replaced by zero.</t>
789      <t>the "corrected_age_value", if all of the caches along the response
790      path implement HTTP/1.1. A cache &MUST; interpret this value relative
791      to the time the request was initiated, not the time that the response
792      was received.</t>
793   </list>
794</t>
795<figure>
796<artwork type="code">
797  apparent_age = max(0, response_time - date_value);
798
799  response_delay = response_time - request_time;
800  corrected_age_value = age_value + response_delay; 
801</artwork>
802</figure>
803<figure>
804<preamble>These are combined as</preamble>
805<artwork type="code">
806  corrected_initial_age = max(apparent_age, corrected_age_value);
807</artwork></figure>
808<t>
809   unless the cache is confident in the value of the <x:ref>Age</x:ref> header
810   field (e.g., because there are no HTTP/1.0 hops in the <x:ref>Via</x:ref>
811   header field), in which case the corrected_age_value &MAY; be used as the
812   corrected_initial_age.
813</t>
814<t>
815   The current_age of a stored response can then be calculated by adding the
816   amount of time (in seconds) since the stored response was last validated by
817   the origin server to the corrected_initial_age.
818</t>
819<figure><artwork type="code">
820  resident_time = now - response_time;
821  current_age = corrected_initial_age + resident_time;
822</artwork></figure>
823</section>
824
825<section anchor="serving.stale.responses" title="Serving Stale Responses">
826<t>
827   A "stale" response is one that either has explicit expiry information or is
828   allowed to have heuristic expiry calculated, but is not fresh according to
829   the calculations in <xref target="expiration.model" />.
830</t>
831<t>
832   A cache &MUST-NOT; generate a stale response if it is prohibited by an
833   explicit in-protocol directive (e.g., by a "no-store" or "no-cache" cache
834   directive, a "must-revalidate" cache-response-directive, or an applicable
835   "s-maxage" or "proxy-revalidate" cache-response-directive; see <xref
836   target="cache-response-directive"/>).
837</t>
838<t>
839   A cache &MUST-NOT; send stale responses unless it is disconnected
840   (i.e., it cannot contact the origin server or otherwise find a forward
841   path) or doing so is explicitly allowed (e.g., by the max-stale request
842   directive; see <xref target="cache-request-directive" />).
843</t>
844<t>
845   A cache &SHOULD; generate a <x:ref>Warning</x:ref> header field with the
846   110 warn-code (see <xref target="warn.110"/>) in stale responses.
847   Likewise, a cache &SHOULD; generate a 112 warn-code (see
848   <xref target="warn.112"/>) in stale responses if the cache is disconnected.
849</t>
850<t>
851   A cache &SHOULD-NOT; generate a new <x:ref>Warning</x:ref> header field
852   when forwarding a response that does not have an <x:ref>Age</x:ref> header
853   field, even if the response is already stale.  A cache need not validate
854   a response that merely became stale in transit.
855</t>
856</section>
857</section>
858
859<section anchor="validation.model" title="Validation">
860<t>
861   When a cache has one or more stored responses for a requested URI, but
862   cannot serve any of them (e.g., because they are not fresh, or one cannot
863   be selected; see <xref target="caching.negotiated.responses"/>), it can use
864   the conditional request mechanism &conditional; in the forwarded request to
865   give the next inbound server an opportunity to select a valid stored
866   response to use, updating the stored metadata in the process, or to replace
867   the stored response(s) with a new response. This process is known as
868   "validating" or "revalidating" the stored response.
869</t>
870
871<section anchor="validation.sent" title="Sending a Validation Request"><iref item="validator" />
872<t>
873   When sending a conditional request for cache validation, a cache sends one
874   or more precondition header fields containing <x:dfn>validator</x:dfn>
875   metadata from its stored response(s), which is then compared by recipients
876   to determine whether a stored response is equivalent to a current
877   representation of the resource.
878</t>
879<t>
880   One such validator is the timestamp given in a <x:ref>Last-Modified</x:ref>
881   header field (&header-last-modified;), which can be used in an
882   <x:ref>If-Modified-Since</x:ref> header field for response validation, or
883   in an <x:ref>If-Unmodified-Since</x:ref> or <x:ref>If-Range</x:ref> header
884   field for representation selection (i.e., the client is referring
885   specifically to a previously obtained representation with that timestamp).
886</t>
887<t>
888   Another validator is the entity-tag given in an <x:ref>ETag</x:ref> header
889   field (&header-etag;). One or more entity-tags, indicating one or more
890   stored responses, can be used in an <x:ref>If-None-Match</x:ref> header
891   field for response validation, or in an <x:ref>If-Match</x:ref> or
892   <x:ref>If-Range</x:ref> header field for representation selection (i.e.,
893   the client is referring specifically to one or more previously obtained
894   representations with the listed entity-tags).
895</t>
896</section>
897
898<section anchor="validation.received" title="Handling a Received Validation Request">
899<t>
900   Each client in the request chain may have its own cache, so it is common
901   for a cache at an intermediary to receive conditional requests from other
902   (outbound) caches. Likewise, some user agents make use of conditional
903   requests to limit data transfers to recently modified representations or to
904   complete the transfer of a partially retrieved representation.
905</t>
906<t>
907   If a cache receives a request that can be satisfied by reusing one of
908   its stored <x:ref>200 (OK)</x:ref> or <x:ref>206 (Partial Content)</x:ref>
909   responses, the cache &SHOULD; evaluate any applicable conditional header
910   field preconditions received in that request with respect to the
911   corresponding validators contained within the selected response.
912   A cache &MUST-NOT; evaluate conditional header fields that are only
913   applicable to an origin server, found in a request with semantics that
914   cannot be satisfied with a cached response, or applied to a target resource
915   for which it has no stored responses; such preconditions are likely
916   intended for some other (inbound) server.
917</t>
918<t>
919   The proper evaluation of conditional requests by a cache depends on the
920   received precondition header fields and their precedence, as defined in
921   &conditional-precedence;. The <x:ref>If-Match</x:ref> and
922   <x:ref>If-Unmodified-Since</x:ref> conditional header fields are not
923   applicable to a cache.
924</t>
925<t>
926   A request containing an <x:ref>If-None-Match</x:ref> header field
927   (&header-if-none-match;) indicates that the client wants to validate one
928   or more of its own stored responses in comparison to whichever stored
929   response is selected by the cache.
930   If the field-value is "*", or if the field-value is a list of entity-tags
931   and at least one of them matches the entity-tag of the selected stored
932   response, a cache recipient &SHOULD; generate a
933   <x:ref>304 (Not Modified)</x:ref> response (using the metadata of the
934   selected stored response) instead of sending that stored response.
935</t>
936<t>
937   When a cache decides to revalidate its own stored responses for a
938   request that contains an <x:ref>If-None-Match</x:ref> list of entity-tags,
939   the cache &MAY; combine the received list with a list of entity-tags
940   from its own stored set of responses (fresh or stale) and send the union of
941   the two lists as a replacement <x:ref>If-None-Match</x:ref> header
942   field value in the forwarded request.
943   If a stored response contains only partial content, the
944   cache &MUST-NOT; include its entity-tag in the union unless the request is
945   for a range that would be fully satisfied by that partial stored response.
946   If the response to the forwarded request is
947   <x:ref>304 (Not Modified)</x:ref> and has an ETag header field value with
948   an entity-tag that is not in the client's list, the cache &MUST;
949   generate a <x:ref>200 (OK)</x:ref> response for the client by reusing its
950   corresponding stored response, as updated by the 304 response metadata
951   (<xref target="freshening.responses"/>).
952</t>
953<t>
954   If an <x:ref>If-None-Match</x:ref> header field is not present, a request
955   containing an <x:ref>If-Modified-Since</x:ref> header field
956   (&header-if-modified-since;) indicates that the client wants to validate
957   one or more of its own stored responses by modification date.
958   A cache recipient &SHOULD; generate a <x:ref>304 (Not Modified)</x:ref>
959   response (using the metadata of the selected stored response) if one of the
960   following cases is true:
961   1) the selected stored response has a <x:ref>Last-Modified</x:ref>
962   field-value that is earlier than or equal to the conditional timestamp;
963   2) no <x:ref>Last-Modified</x:ref> field is present in the selected stored
964   response, but it has a <x:ref>Date</x:ref> field-value that is earlier than
965   or equal to the conditional timestamp; or,
966   3) neither <x:ref>Last-Modified</x:ref> nor <x:ref>Date</x:ref> is present
967   in the selected stored response, but the cache recorded it as having been
968   received at a time earlier than or equal to the conditional timestamp.
969</t>
970<t>
971   A cache that implements partial responses to range requests, as defined in
972   &partial;, also needs to evaluate a received <x:ref>If-Range</x:ref> header
973   field (&header-if-range;) with respect to its selected stored response.
974</t>
975</section>
976
977<section anchor="validation.response" title="Handling a Validation Response">
978<t>
979   Cache handling of a response to a conditional request is dependent upon its
980   status code:
981</t>
982<t>
983   <list style="symbols">
984      <t>
985         A <x:ref>304 (Not Modified)</x:ref> response status code indicates
986         that the stored response can be updated and reused; see <xref
987         target="freshening.responses"/>.
988      </t>
989      <t>
990         A full response (i.e., one with a payload body) indicates that none
991         of the stored responses nominated in the conditional request is
992         suitable. Instead, the cache &MUST; use the full response to
993         satisfy the request and &MAY; replace the stored response(s).
994      </t>
995      <t>
996         However, if a cache receives a <x:ref>5xx (Server Error)</x:ref>
997         response while attempting to validate a response, it can either
998         forward this response to the requesting client, or act as if the
999         server failed to respond. In the latter case, the cache &MAY; send a
1000         previously stored response (see <xref
1001         target="serving.stale.responses" />).
1002      </t>
1003   </list>
1004</t>
1005</section>
1006
1007<section anchor="freshening.responses" title="Freshening Stored Responses upon Validation">
1008<t>
1009   When a cache receives a <x:ref>304 (Not Modified)</x:ref> response and
1010   already has one or more stored <x:ref>200 (OK)</x:ref> responses for the
1011   same cache key, the cache needs to identify which of the stored responses
1012   are updated by this new response and then update the stored response(s)
1013   with the new information provided in the <x:ref>304</x:ref> response.
1014</t>
1015<iref item="strong validator" />
1016<t>
1017   The stored response to update is identified by using the first match (if
1018   any) of the following:
1019   <list style="symbols">
1020    <t>
1021     If the new response contains a <x:dfn>strong validator</x:dfn> (see
1022     &weak-and-strong;), then that strong validator identifies the selected
1023     representation for update. All of the stored responses with the same
1024     strong validator are selected. If none of the stored responses contain the
1025     same strong validator, then the cache &MUST-NOT; use the new response to
1026     update any stored responses.
1027    </t>
1028    <t>
1029     If the new response contains a weak validator and that validator
1030     corresponds to one of the cache's stored responses, then the most
1031     recent of those matching stored responses is selected for update.
1032    </t>
1033    <t>
1034     If the new response does not include any form of validator (such as in
1035     the case where a client generates an If-Modified-Since request from a
1036     source other than the Last-Modified response header field), and there is
1037     only one stored response, and that stored response also lacks a
1038     validator, then that stored response is selected for update.
1039    </t>
1040   </list>
1041</t>
1042<t>
1043   If a stored response is selected for update, the cache &MUST;:
1044   <list style="symbols">
1045      <t>delete any <x:ref>Warning</x:ref> header fields in the stored response
1046         with warn-code 1xx (see <xref target="header.warning" />);</t>
1047      <t>retain any <x:ref>Warning</x:ref> header fields in the stored response
1048         with warn-code 2xx; and,</t>
1049      <t>use other header fields provided in the <x:ref>304 (Not Modified)</x:ref>
1050         response to replace all instances of the corresponding header
1051         fields in the stored response.</t>
1052   </list>
1053</t>
1054</section>
1055
1056<section anchor="head.effects" title="Freshening Responses via HEAD">
1057<t>
1058   A response to the HEAD method is identical to what an equivalent request
1059   made with a GET would have been, except it lacks a body. This property
1060   of HEAD responses can be used to invalidate or update a cached GET
1061   response if the more efficient conditional GET request mechanism is not
1062   available (due to no validators being present in the stored response) or
1063   if transmission of the representation body is not desired even if it has
1064   changed.
1065</t>
1066<t>
1067   When a cache makes an inbound HEAD request for a given request target and
1068   receives a <x:ref>200 (OK)</x:ref> response, the cache &SHOULD; update or
1069   invalidate each of its stored GET responses that could have been selected
1070   for that request (see <xref target="caching.negotiated.responses"/>).
1071</t>
1072<t>
1073   For each of the stored responses that could have been selected, if the
1074   stored response and HEAD response have matching values for any received
1075   validator fields (<x:ref>ETag</x:ref> and <x:ref>Last-Modified</x:ref>)
1076   and, if the HEAD response has a <x:ref>Content-Length</x:ref> header field,
1077   the value of <x:ref>Content-Length</x:ref> matches that of the stored
1078   response, the cache &SHOULD; update the stored response as described below;
1079   otherwise, the cache &SHOULD; consider the stored response to be stale.
1080</t>
1081<t>
1082   If a cache updates a stored response with the metadata provided in a HEAD
1083   response, the cache &MUST;:
1084   <list style="symbols">
1085      <t>delete any <x:ref>Warning</x:ref> header fields in the stored response
1086         with warn-code 1xx (see <xref target="header.warning" />);</t>
1087      <t>retain any <x:ref>Warning</x:ref> header fields in the stored response
1088         with warn-code 2xx; and,</t>
1089      <t>use other header fields provided in the HEAD response to replace all
1090         instances of the corresponding header fields in the stored response
1091         and append new header fields to the stored response's header section
1092         unless otherwise restricted by the <x:ref>Cache-Control</x:ref>
1093         header field.</t>
1094   </list>
1095</t>
1096</section>
1097</section>
1098
1099
1100<section anchor="invalidation" title="Invalidation">
1101<t>
1102   Because unsafe request methods (&safe-methods;) such as PUT, POST or DELETE
1103   have the potential for changing state on the origin server, intervening
1104   caches can use them to keep their contents up to date.
1105</t>
1106<t>
1107   A cache &MUST; invalidate the effective Request URI
1108   (&effective-request-uri;) as well as the URI(s) in the
1109   <x:ref>Location</x:ref> and <x:ref>Content-Location</x:ref> response header
1110   fields (if present) when a non-error status code is received in response to
1111   an unsafe request method.
1112</t>
1113<t>
1114   However, a cache &MUST-NOT; invalidate a URI from a <x:ref>Location</x:ref>
1115   or <x:ref>Content-Location</x:ref> response header field if the host part of
1116   that URI differs from the host part in the effective request URI
1117   (&effective-request-uri;). This helps prevent denial-of-service attacks.
1118</t>
1119<t>
1120   A cache &MUST; invalidate the effective request URI
1121   (&effective-request-uri;) when it receives a non-error response
1122   to a request with a method whose safety is unknown.
1123</t>
1124<t>
1125   Here, a "non-error response" is one with a <x:ref>2xx (Successful)</x:ref>
1126   or <x:ref>3xx (Redirection)</x:ref> status code. "Invalidate" means that
1127   the cache will either remove all stored responses related to the effective
1128   request URI or will mark these as "invalid" and in need of a mandatory
1129   validation before they can be sent in response to a subsequent request.
1130</t>
1131<t>
1132   Note that this does not guarantee that all appropriate responses are
1133   invalidated. For example, a state-changing request might invalidate
1134   responses in the caches it travels through, but relevant responses still
1135   might be stored in other caches that it has not.</t>
1136</section>
1137</section>
1138
1139
1140
1141<section anchor="header.field.definitions" title="Header Field Definitions">
1142<t>
1143   This section defines the syntax and semantics of HTTP/1.1 header fields
1144   related to caching.
1145</t>
1146
1147<section anchor="header.age" title="Age">
1148   <iref item="Age header field" primary="true" x:for-anchor="" />
1149   <x:anchor-alias value="Age"/>
1150   <x:anchor-alias value="age-value"/>
1151<t>
1152   The "Age" header field conveys the sender's estimate of the amount
1153   of time since the response was generated or successfully validated at the
1154   origin server. Age values are calculated as specified in <xref
1155   target="age.calculations" />.
1156</t>
1157<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Age"/>
1158  <x:ref>Age</x:ref> = <x:ref>delta-seconds</x:ref>
1159</artwork></figure>
1160<t>
1161   The Age field-value is a non-negative integer, representing time in seconds
1162   (see <xref target="delta-seconds"/>).
1163</t>
1164<t>
1165   The presence of an Age header field implies that the response was not
1166   generated or validated by the origin server for this request. However,
1167   lack of an Age header field does not imply the origin was contacted, since
1168   the response might have been received from an HTTP/1.0 cache that does not
1169   implement Age.
1170</t>
1171</section>
1172
1173<section anchor="header.cache-control" title="Cache-Control">
1174   <iref item="Cache-Control header field" primary="true" x:for-anchor="" />
1175   <x:anchor-alias value="Cache-Control"/>
1176   <x:anchor-alias value="cache-directive"/>
1177<t>
1178   The "Cache-Control" header field is used to specify directives for
1179   caches along the request/response chain. Such cache directives are
1180   unidirectional in that the presence of a directive in a request does not
1181   imply that the same directive is to be given in the response.
1182</t>
1183<t>
1184   A cache &MUST; obey the requirements of the Cache-Control
1185   directives defined in this section. See <xref
1186   target="cache.control.extensions"/> for information about how Cache-Control
1187   directives defined elsewhere are handled.
1188</t>
1189<x:note>
1190   <t>
1191       &Note; Some HTTP/1.0 caches might not implement Cache-Control.
1192   </t>
1193</x:note>
1194<t>
1195   A proxy, whether or not it implements a cache, &MUST; pass cache directives
1196   through in forwarded messages, regardless of their
1197   significance to that application, since the directives might be applicable
1198   to all recipients along the request/response chain. It is not possible to
1199   target a directive to a specific cache.
1200</t>
1201<t>
1202   Cache directives are identified by a token, to be compared case-insensitively,
1203   and have an optional argument, that can use both token and quoted-string
1204   syntax. For the directives defined below that define arguments, recipients
1205   ought to accept both forms, even if one is documented to be preferred. For
1206   any directive not defined by this specification, a recipient &MUST; accept
1207   both forms.
1208</t>
1209<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Cache-Control"/><iref primary="true" item="Grammar" subitem="cache-directive"/>
1210  <x:ref>Cache-Control</x:ref>   = 1#<x:ref>cache-directive</x:ref>
1211
1212  <x:ref>cache-directive</x:ref> = <x:ref>token</x:ref> [ "=" ( <x:ref>token</x:ref> / <x:ref>quoted-string</x:ref> ) ]
1213</artwork></figure>
1214<t>
1215   For the cache directives defined below, no argument is defined (nor allowed)
1216   unless stated otherwise.
1217</t>
1218
1219<section title="Request Cache-Control Directives" anchor="cache-request-directive">
1220
1221<section title="max-age" anchor="cache-request-directive.max-age">
1222   <iref item="max-age (cache directive)" primary="true" />
1223<t>
1224   Argument syntax:
1225   <list>
1226      <t>
1227        <x:ref>delta-seconds</x:ref> (see <xref target="delta-seconds"/>)
1228      </t>
1229   </list>
1230</t>
1231<t>
1232   The "max-age" request directive indicates that the client is unwilling
1233   to accept a response whose age is greater than the specified number of
1234   seconds. Unless the max-stale request directive is also present, the client
1235   is not willing to accept a stale response.
1236</t>
1237<t>
1238   This directive uses the token form of the argument syntax:
1239   e.g., 'max-age=5' not 'max-age="5"'. A sender &SHOULD-NOT; generate the
1240   quoted-string form.
1241</t>
1242</section>
1243
1244<section title="max-stale" anchor="cache-request-directive.max-stale">
1245   <iref item="max-stale (cache directive)" primary="true" />
1246<t>
1247   Argument syntax:
1248   <list>
1249      <t>
1250        <x:ref>delta-seconds</x:ref> (see <xref target="delta-seconds"/>)
1251      </t>
1252   </list>
1253</t>
1254<t>
1255   The "max-stale" request directive indicates that the client is willing
1256   to accept a response that has exceeded its freshness lifetime. If max-stale
1257   is assigned a value, then the client is willing to accept a response
1258   that has exceeded its freshness lifetime by no more than the specified
1259   number of seconds. If no value is assigned to max-stale, then the client
1260   is willing to accept a stale response of any age.
1261</t>
1262<t>
1263   This directive uses the token form of the argument syntax:
1264   e.g., 'max-stale=10' not 'max-stale="10"'. A sender &SHOULD-NOT; generate
1265   the quoted-string form.
1266</t>
1267</section>
1268
1269<section title="min-fresh" anchor="cache-request-directive.min-fresh">
1270   <iref item="min-fresh (cache directive)" primary="true" />
1271<t>
1272   Argument syntax:
1273   <list>
1274      <t>
1275        <x:ref>delta-seconds</x:ref> (see <xref target="delta-seconds"/>)
1276      </t>
1277   </list>
1278</t>
1279<t>
1280   The "min-fresh" request directive indicates that the client is willing
1281   to accept a response whose freshness lifetime is no less than its
1282   current age plus the specified time in seconds. That is, the client
1283   wants a response that will still be fresh for at least the specified
1284   number of seconds.
1285</t>
1286<t>
1287   This directive uses the token form of the argument syntax:
1288   e.g., 'min-fresh=20' not 'min-fresh="20"'. A sender &SHOULD-NOT; generate
1289   the quoted-string form.
1290</t>
1291</section>
1292
1293<section title="no-cache" anchor="cache-request-directive.no-cache">
1294   <iref item="no-cache (cache directive)" primary="true" />
1295<t>
1296   The "no-cache" request directive indicates that a cache &MUST-NOT; 
1297   use a stored response to satisfy the request without successful
1298   validation on the origin server.
1299</t>
1300</section>
1301 
1302<section title="no-store" anchor="cache-request-directive.no-store">
1303   <iref item="no-store (cache directive)" primary="true" />
1304<t>
1305   The "no-store" request directive indicates that a cache &MUST-NOT;
1306   store any part of either this request or any response to it. This
1307   directive applies to both private and shared caches. "&MUST-NOT;
1308   store" in this context means that the cache &MUST-NOT; intentionally
1309   store the information in non-volatile storage, and &MUST; make a
1310   best-effort attempt to remove the information from volatile storage as
1311   promptly as possible after forwarding it.
1312</t>
1313<t>
1314   This directive is NOT a reliable or sufficient mechanism for ensuring
1315   privacy. In particular, malicious or compromised caches might not
1316   recognize or obey this directive, and communications networks might be
1317   vulnerable to eavesdropping.
1318</t>
1319<t>
1320   Note that if a request containing this directive is satisfied from a
1321   cache, the no-store request directive does not apply to the already
1322   stored response.
1323</t>
1324</section>
1325
1326<section title="no-transform" anchor="cache-request-directive.no-transform">
1327   <iref item="no-transform (cache directive)" primary="true" />
1328<t>
1329   The "no-transform" request directive indicates that an intermediary
1330   (whether or not it implements a cache) &MUST-NOT; transform the payload,
1331   as defined in &transformations;.
1332</t>
1333</section>
1334
1335<section title="only-if-cached" anchor="cache-request-directive.only-if-cached">
1336   <iref item="only-if-cached (cache directive)" primary="true" />
1337<t>
1338   The "only-if-cached" request directive indicates that the client only wishes
1339   to obtain a stored response. If it receives this directive, a cache &SHOULD;
1340   either respond using a stored response that is consistent with the other
1341   constraints of the request, or respond with a <x:ref>504 (Gateway
1342   Timeout)</x:ref> status code. If a group of caches is being operated as a
1343   unified system with good internal connectivity, a member cache &MAY;
1344   forward such a request within that group of caches.
1345</t>
1346</section>
1347</section>
1348
1349<section anchor="cache-response-directive" 
1350   title="Response Cache-Control Directives">
1351   <x:anchor-alias value="cache-response-directive" />
1352
1353<section title="must-revalidate" anchor="cache-response-directive.must-revalidate">
1354   <iref item="must-revalidate (cache directive)" primary="true" />
1355<t>
1356   The "must-revalidate" response directive indicates that once it has
1357   become stale, a cache &MUST-NOT; use the response to satisfy subsequent
1358   requests without successful validation on the origin server.
1359</t>
1360<t>
1361   The must-revalidate directive is necessary to support reliable
1362   operation for certain protocol features. In all circumstances a
1363   cache &MUST; obey the must-revalidate directive; in particular,
1364   if a cache cannot reach the origin server for any reason, it &MUST;
1365   generate a <x:ref>504 (Gateway Timeout)</x:ref> response.
1366</t>
1367<t>
1368   The must-revalidate directive ought to be used by servers if and only
1369   if failure to validate a request on the representation could result in
1370   incorrect operation, such as a silently unexecuted financial
1371   transaction.
1372</t>
1373</section>
1374
1375<section title="no-cache" anchor="cache-response-directive.no-cache">
1376   <iref item="no-cache (cache directive)" primary="true" />
1377<t>
1378   Argument syntax:
1379   <list>
1380      <t>
1381        #<x:ref>field-name</x:ref>
1382      </t>
1383   </list>
1384</t>
1385<t>
1386   The "no-cache" response directive indicates that the response &MUST-NOT;
1387   be used to satisfy a subsequent request without successful validation on
1388   the origin server. This allows an origin server to prevent a cache from
1389   using it to satisfy a request without contacting it, even by caches that
1390   have been configured to send stale responses.
1391</t>
1392<t>
1393   If the no-cache response directive specifies one or more field-names,
1394   then a cache &MAY; use the response to satisfy a subsequent request,
1395   subject to any other restrictions on caching. However, any header fields
1396   in the response that have the field-name(s) listed &MUST-NOT; be sent
1397   in the response to a subsequent request without successful revalidation
1398   with the origin server. This allows an origin server to prevent the
1399   re-use of certain header fields in a response, while still allowing
1400   caching of the rest of the response.
1401</t> 
1402<t>
1403   The field-names given are not limited to the set of header
1404   fields defined by this specification. Field names are case-insensitive.
1405</t>
1406<t>
1407   This directive uses the quoted-string form of the argument syntax.
1408   A sender &SHOULD-NOT; generate the token form (even if quoting appears not
1409   to be needed for single-entry lists).
1410</t>
1411<t>
1412   &Note; Although it has been back-ported to many implementations, some
1413   HTTP/1.0 caches will not recognize or obey this directive. Also, no-cache
1414   response directives with field-names are often handled by caches
1415   as if an unqualified no-cache directive was received; i.e., the special
1416   handling for the qualified form is not widely implemented.
1417</t>
1418</section>
1419
1420<section title="no-store" anchor="cache-response-directive.no-store">
1421   <iref item="no-store (cache directive)" primary="true" />
1422<t>
1423   The "no-store" response directive indicates that a cache &MUST-NOT;
1424   store any part of either the immediate request or response. This
1425   directive applies to both private and shared caches. "&MUST-NOT;
1426   store" in this context means that the cache &MUST-NOT; intentionally
1427   store the information in non-volatile storage, and &MUST; make a
1428   best-effort attempt to remove the information from volatile storage as
1429   promptly as possible after forwarding it.
1430</t>
1431<t>
1432   This directive is NOT a reliable or sufficient mechanism for ensuring
1433   privacy. In particular, malicious or compromised caches might not
1434   recognize or obey this directive, and communications networks might be
1435   vulnerable to eavesdropping.
1436</t>
1437</section>
1438
1439<section title="no-transform" anchor="cache-response-directive.no-transform">
1440   <iref item="no-transform (cache directive)" primary="true" />
1441<t>
1442   The "no-transform" response directive indicates that an intermediary
1443   (regardless of whether it implements a cache) &MUST-NOT; transform the
1444   payload, as defined in &transformations;.
1445</t>
1446</section>
1447
1448<section title="public" anchor="cache-response-directive.public">
1449   <iref item="public (cache directive)" primary="true" />
1450<t>
1451   The "public" response directive indicates that any cache &MAY; store the
1452   response, even if the response would normally be non-cacheable or cacheable
1453   only within a private cache. (See <xref
1454   target="caching.authenticated.responses"/> for additional details related to
1455   the use of public in response to a request containing
1456   <x:ref>Authorization</x:ref>, and <xref target="response.cacheability"/> for
1457   details of how public affects responses that would normally not be stored,
1458   due to their status codes not being defined as cacheable by default; see
1459   <xref target="heuristic.freshness"/>.)
1460</t>
1461</section>
1462
1463<section title="private" anchor="cache-response-directive.private">
1464   <iref item="private (cache directive)" primary="true" />
1465<t>
1466   Argument syntax:
1467   <list>
1468      <t>
1469        #<x:ref>field-name</x:ref>
1470      </t>
1471   </list>
1472</t>
1473<t>
1474   The "private" response directive indicates that the response message is
1475   intended for a single user and &MUST-NOT; be stored by a shared cache. A
1476   private cache &MAY; store the response and reuse it for later requests,
1477   even if the response would normally be non-cacheable.
1478</t>
1479<t>
1480   If the private response directive specifies one or more field-names,
1481   this requirement is limited to the field-values associated with the
1482   listed response header fields. That is, a shared cache &MUST-NOT; store
1483   the specified field-names(s), whereas it &MAY; store the remainder of the
1484   response message.
1485</t>
1486<t>
1487   The field-names given are not limited to the set of header
1488   fields defined by this specification. Field names are case-insensitive.
1489</t>
1490<t>
1491   This directive uses the quoted-string form of the argument syntax.
1492   A sender &SHOULD-NOT; generate the token form (even if quoting appears not
1493   to be needed for single-entry lists).
1494</t>
1495<t>
1496   &Note; This usage of the word "private" only controls
1497   where the response can be stored; it cannot ensure the privacy of the
1498   message content. Also, private response directives with field-names are
1499   often handled by caches as if an unqualified private directive
1500   was received; i.e., the special handling for the qualified form is not
1501   widely implemented.
1502</t>
1503</section>
1504
1505<section title="proxy-revalidate" anchor="cache-response-directive.proxy-revalidate">
1506   <iref item="proxy-revalidate (cache directive)" primary="true" />
1507<t>
1508   The "proxy-revalidate" response directive has the same meaning as the
1509   must-revalidate response directive, except that it does not apply to
1510   private caches.
1511</t>
1512</section>
1513
1514<section title="max-age" anchor="cache-response-directive.max-age">
1515   <iref item="max-age (cache directive)" primary="true" />
1516<t>
1517   Argument syntax:
1518   <list>
1519      <t>
1520        <x:ref>delta-seconds</x:ref> (see <xref target="delta-seconds"/>)
1521      </t>
1522   </list>
1523</t>
1524<t>
1525   The "max-age" response directive indicates that the response is to be
1526   considered stale after its age is greater than the specified number of
1527   seconds.
1528</t>
1529<t>
1530   This directive uses the token form of the argument syntax:
1531   e.g., 'max-age=5' not 'max-age="5"'. A sender &SHOULD-NOT; generate the
1532   quoted-string form.
1533</t>
1534</section>     
1535
1536<section title="s-maxage" anchor="cache-response-directive.s-maxage">
1537   <iref item="s-maxage (cache directive)" primary="true" />
1538<t>
1539   Argument syntax:
1540   <list>
1541      <t>
1542        <x:ref>delta-seconds</x:ref> (see <xref target="delta-seconds"/>)
1543      </t>
1544   </list>
1545</t>
1546<t>
1547   The "s-maxage" response directive indicates that, in shared caches, the
1548   maximum age specified by this directive overrides the maximum age
1549   specified by either the max-age directive or the <x:ref>Expires</x:ref>
1550   header field. The s-maxage directive also implies the semantics of the
1551   proxy-revalidate response directive.
1552</t>
1553<t>
1554   This directive uses the token form of the argument syntax:
1555   e.g., 's-maxage=10' not 's-maxage="10"'. A sender &SHOULD-NOT; generate
1556   the quoted-string form.
1557</t>
1558</section>
1559
1560</section>
1561
1562<section anchor="cache.control.extensions" title="Cache Control Extensions">
1563<t>
1564   The Cache-Control header field can be extended through the use of one or
1565   more cache-extension tokens, each with an optional value.
1566   A cache &MUST; ignore unrecognized cache directives.
1567</t>
1568<t>
1569   Informational extensions (those that do not require a change in cache
1570   behavior) can be added without changing the semantics of other directives.
1571</t>
1572<t>   
1573   Behavioral extensions are designed to work by acting as modifiers to the
1574   existing base of cache directives.
1575   Both the new directive and the old directive are supplied, such that
1576   applications that do not understand the new directive will default to the
1577   behavior specified by the old directive, and those that understand the
1578   new directive will recognize it as modifying the requirements associated
1579   with the old directive. In this way, extensions to the existing
1580   cache-control directives can be made without breaking deployed caches.
1581</t>
1582<t>
1583   For example, consider a hypothetical new response directive called
1584   "community" that acts as a modifier to the private directive: in addition
1585   to private caches, any cache that is shared only by members of the named
1586   community is allowed to cache the response. An origin server wishing to
1587   allow the UCI community to use an otherwise private response in their
1588   shared cache(s) could do so by including
1589</t>
1590<figure><artwork type="example">
1591  Cache-Control: private, community="UCI"
1592</artwork></figure>
1593<t>
1594   A cache that recognizes such a community cache-extension could broaden its
1595   behavior in accordance with that extension.  A cache that does not
1596   recognize the community cache-extension would ignore it and adhere to the
1597   private directive.
1598</t>
1599</section>
1600
1601</section>
1602
1603<section anchor="header.expires" title="Expires">
1604   <iref item="Expires header field" primary="true" x:for-anchor="" />
1605   <x:anchor-alias value="Expires"/>
1606<t>
1607   The "Expires" header field gives the date/time after which the
1608   response is considered stale. See <xref target="expiration.model" /> for
1609   further discussion of the freshness model.
1610</t>
1611<t>
1612   The presence of an Expires field does not imply that the original resource
1613   will change or cease to exist at, before, or after that time.
1614</t>
1615<t>
1616   The Expires value is an HTTP-date timestamp, as defined in &http-date;.
1617</t>
1618<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Expires"/>
1619  <x:ref>Expires</x:ref> = <x:ref>HTTP-date</x:ref>
1620</artwork></figure>
1621<figure>
1622  <preamble>For example</preamble>
1623<artwork type="example">
1624  Expires: Thu, 01 Dec 1994 16:00:00 GMT
1625</artwork></figure>
1626<t>
1627   A cache recipient &MUST; interpret invalid date formats, especially the
1628   value "0", as representing a time in the past (i.e., "already expired").
1629</t>
1630<t>
1631   If a response includes a <x:ref>Cache-Control</x:ref> field with
1632   the max-age directive (<xref target="cache-response-directive.max-age"/>),
1633   a recipient &MUST; ignore the Expires field.
1634   Likewise, if a response includes the s-maxage directive
1635   (<xref target="cache-response-directive.s-maxage" />), a shared cache
1636   recipient &MUST; ignore the Expires field. In both these cases, the value
1637   in Expires is only intended for recipients that have not yet implemented
1638   the Cache-Control field.
1639</t>
1640<t>
1641   An origin server without a clock &MUST-NOT; generate an Expires field
1642   unless its value represents a fixed time in the past (always expired)
1643   or its value has been associated with the resource by a system or user
1644   with a reliable clock.
1645</t>
1646<t>
1647   Historically, HTTP required the Expires field-value to be no more than a
1648   year in the future. While longer freshness lifetimes are no longer
1649   prohibited, extremely large values have been demonstrated to cause
1650   problems (e.g., clock overflows due to use of 32-bit integers for
1651   time values), and many caches will evict a response far sooner than
1652   that.
1653</t>
1654</section>
1655
1656<section anchor="header.pragma" title="Pragma">
1657   <iref item="Pragma header field" primary="true" x:for-anchor="" />
1658   <x:anchor-alias value="extension-pragma"/>
1659   <x:anchor-alias value="Pragma"/>
1660   <x:anchor-alias value="pragma-directive"/>
1661<t>
1662   The "Pragma" header field allows backwards compatibility with HTTP/1.0
1663   caches, so that clients can specify a "no-cache" request that they will
1664   understand (as <x:ref>Cache-Control</x:ref> was not defined until HTTP/1.1).
1665   When the Cache-Control header field is also present and understood in a
1666   request, Pragma is ignored.
1667</t>
1668<t>
1669   In HTTP/1.0, Pragma was defined as an extensible field for
1670   implementation-specified directives for recipients. This specification
1671   deprecates such extensions to improve interoperability.
1672</t>
1673<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Pragma"/><iref primary="true" item="Grammar" subitem="pragma-directive"/><iref primary="true" item="Grammar" subitem="extension-pragma"/>
1674  <x:ref>Pragma</x:ref>           = 1#<x:ref>pragma-directive</x:ref>
1675  <x:ref>pragma-directive</x:ref> = "no-cache" / <x:ref>extension-pragma</x:ref>
1676  <x:ref>extension-pragma</x:ref> = <x:ref>token</x:ref> [ "=" ( <x:ref>token</x:ref> / <x:ref>quoted-string</x:ref> ) ]
1677</artwork></figure>
1678<t>
1679   When the <x:ref>Cache-Control</x:ref> header field is not present in a
1680   request, caches &MUST; consider the no-cache request pragma-directive as
1681   having the same effect as if "Cache-Control: no-cache" were present (see
1682   <xref target="cache-request-directive" />).
1683</t>
1684<t>
1685   When sending a no-cache request, a client ought to include both the pragma
1686   and cache-control directives, unless Cache-Control: no-cache is
1687   purposefully omitted to target other <x:ref>Cache-Control</x:ref> response
1688   directives at HTTP/1.1 caches. For example:
1689</t>
1690<figure>
1691<artwork type="message/http; msgtype=&#34;response&#34;" x:indent-with="  ">
1692GET / HTTP/1.1
1693Host: www.example.com
1694Cache-Control: max-age=30
1695Pragma: no-cache
1696
1697</artwork>
1698</figure>
1699<t>
1700   will constrain HTTP/1.1 caches to serve a response no older than 30
1701   seconds, while precluding implementations that do not understand
1702   <x:ref>Cache-Control</x:ref> from serving a cached response.
1703</t>
1704<x:note>
1705   <t>
1706      &Note; Because the meaning of "Pragma: no-cache" in responses is not
1707      specified, it does not provide a reliable replacement for
1708      "Cache-Control: no-cache" in them.
1709   </t>
1710</x:note>
1711</section>
1712
1713<section anchor="header.warning" title="Warning">
1714   <iref item="Warning header field" primary="true" x:for-anchor="" />
1715   <x:anchor-alias value="Warning"/>
1716   <x:anchor-alias value="warning-value"/>
1717   <x:anchor-alias value="warn-agent"/>
1718   <x:anchor-alias value="warn-code"/>
1719   <x:anchor-alias value="warn-date"/>
1720   <x:anchor-alias value="warn-text"/>
1721<t>
1722   The "Warning" header field is used to carry additional information
1723   about the status or transformation of a message that might not be reflected
1724   in the status code. This information is typically used to warn about possible
1725   incorrectness introduced by caching operations or transformations applied
1726   to the payload of the message.
1727</t>
1728<t>
1729   Warnings can be used for other purposes, both cache-related and otherwise.
1730   The use of a warning, rather than an error status code, distinguishes these
1731   responses from true failures.
1732</t>
1733<t>
1734   Warning header fields can in general be applied to any message, however some
1735   warn-codes are specific to caches and can only be applied to response
1736   messages.
1737</t>
1738<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Warning"/><iref primary="true" item="Grammar" subitem="warning-value"/><iref primary="true" item="Grammar" subitem="warn-code"/><iref primary="true" item="Grammar" subitem="warn-agent"/><iref primary="true" item="Grammar" subitem="warn-text"/><iref primary="true" item="Grammar" subitem="warn-date"/>
1739  <x:ref>Warning</x:ref>       = 1#<x:ref>warning-value</x:ref>
1740 
1741  <x:ref>warning-value</x:ref> = <x:ref>warn-code</x:ref> <x:ref>SP</x:ref> <x:ref>warn-agent</x:ref> <x:ref>SP</x:ref> <x:ref>warn-text</x:ref>
1742                                        [ <x:ref>SP</x:ref> <x:ref>warn-date</x:ref> ]
1743 
1744  <x:ref>warn-code</x:ref>  = 3<x:ref>DIGIT</x:ref>
1745  <x:ref>warn-agent</x:ref> = ( <x:ref>uri-host</x:ref> [ ":" <x:ref>port</x:ref> ] ) / <x:ref>pseudonym</x:ref>
1746                  ; the name or pseudonym of the server adding
1747                  ; the Warning header field, for use in debugging
1748                  ; a single "-" is recommended when agent unknown
1749  <x:ref>warn-text</x:ref>  = <x:ref>quoted-string</x:ref>
1750  <x:ref>warn-date</x:ref>  = <x:ref>DQUOTE</x:ref> <x:ref>HTTP-date</x:ref> <x:ref>DQUOTE</x:ref>
1751</artwork></figure>
1752<t>
1753   Multiple warnings can be generated in a response (either by the origin
1754   server or by a cache), including multiple warnings with the same warn-code
1755   number that only differ in warn-text.
1756</t>
1757<t>
1758   A user agent that receives one or more Warning header fields &SHOULD;
1759   inform the user of as many of them as possible, in the order that they
1760   appear in the response. Senders that generate multiple Warning header
1761   fields are encouraged to order them with this user agent behavior in mind.
1762   A sender that generates new Warning header fields &MUST; append them after
1763   any existing Warning header fields.
1764</t>
1765<t>
1766   Warnings are assigned three digit warn-codes. The first digit indicates
1767   whether the Warning is required to be deleted from a stored response after
1768   validation:
1769   <list style="symbols">
1770      <t>1xx warn-codes describe the freshness or validation status of the
1771      response, and so they &MUST; be deleted by a cache after validation. They can
1772      only be generated by a cache when validating a cached entry, and
1773      &MUST-NOT; be generated in any other situation.</t>
1774      <t>2xx warn-codes describe some aspect of the representation that is not
1775      rectified by a validation (for example, a lossy compression of the
1776      representation) and they &MUST-NOT; be deleted by a cache after validation,
1777      unless a full response is sent, in which case they &MUST; be.</t>
1778   </list>
1779</t>
1780<t>
1781   If a sender generates one or more 1xx warn-codes in a message to be
1782   sent to a recipient known to implement only HTTP/1.0, the sender &MUST;
1783   include in each corresponding warning-value a warn-date that matches the
1784   <x:ref>Date</x:ref> header field in the message. For example:
1785</t>
1786<figure><artwork type="message/http; msgtype=&#34;response&#34;" x:indent-with="  ">
1787HTTP/1.1 200 OK
1788Date: Sat, 25 Aug 2012 23:34:45 GMT
1789Warning: 112 - "network down" "Sat, 25 Aug 2012 23:34:45 GMT"
1790
1791</artwork></figure>
1792<t>
1793  Warnings have accompanying warn-text that describes the error, e.g., for
1794  logging. It is advisory only, and its content does not affect interpretation
1795  of the warn-code.
1796</t>
1797<t>
1798   If a recipient that uses, evaluates, or displays Warning header fields
1799   receives a warn-date that is different from the <x:ref>Date</x:ref> value
1800   in the same message, the recipient &MUST; exclude the warning-value
1801   containing that warn-date before storing, forwarding, or using the message.
1802   This allows recipients to exclude warning-values that were improperly
1803   retained after a cache validation.
1804   If all of the warning-values are excluded, the recipient &MUST; exclude
1805   the Warning header field as well.
1806</t>
1807<t>
1808   The following warn-codes are defined by this specification, each with a
1809   recommended warn-text in English, and a description of its meaning.
1810   The procedure for defining additional warn codes is described in
1811   <xref target="warn.code.registry.procedure"/>.
1812</t>
1813
1814<section title='Warning: 110 - "Response is Stale"' anchor="warn.110">
1815  <iref primary="true" item="110 (warn-code)" x:for-anchor=""/>
1816  <iref primary="true" item="Response is Stale (warn-text)" x:for-anchor=""/>
1817<t>
1818   A cache &SHOULD; generate this whenever the sent response is stale.
1819</t>
1820</section>
1821
1822<section title='Warning: 111 - "Revalidation Failed"' anchor="warn.111">
1823  <iref primary="true" item="111 (warn-code)" x:for-anchor=""/>
1824  <iref primary="true" item="Revalidation Failed (warn-text)" x:for-anchor=""/>
1825<t>
1826   A cache &SHOULD; generate this when sending a stale response because an
1827   attempt to validate the response failed, due to an inability to reach
1828   the server.
1829</t>
1830</section>
1831
1832<section title='Warning: 112 - "Disconnected Operation"' anchor="warn.112">
1833  <iref primary="true" item="112 (warn-code)" x:for-anchor=""/>
1834  <iref primary="true" item="Disconnected Operation (warn-text)" x:for-anchor=""/>
1835<t>
1836   A cache &SHOULD; generate this if it is intentionally disconnected from
1837   the rest of the network for a period of time.
1838</t>
1839</section>
1840
1841<section title='Warning: 113 - "Heuristic Expiration"' anchor="warn.113">
1842  <iref primary="true" item="113 (warn-code)" x:for-anchor=""/>
1843  <iref primary="true" item="Heuristic Expiration (warn-text)" x:for-anchor=""/>
1844<t>
1845   A cache &SHOULD; generate this if it heuristically chose a freshness
1846   lifetime greater than 24 hours and the response's age is greater than 24
1847   hours.
1848</t>
1849</section>
1850
1851<section title='Warning: 199 - "Miscellaneous Warning"' anchor="warn.199">
1852  <iref primary="true" item="199 (warn-code)" x:for-anchor=""/>
1853  <iref primary="true" item="Miscellaneous Warning (warn-text)" x:for-anchor=""/>
1854<t>
1855   The warning text can include arbitrary information to be presented to
1856   a human user or logged. A system receiving this warning &MUST-NOT; take
1857   any automated action, besides presenting the warning to the user.
1858</t>
1859</section>
1860
1861<section title='Warning: 214 - "Transformation Applied"' anchor="warn.214">
1862  <iref primary="true" item="214 (warn-code)" x:for-anchor=""/>
1863  <iref primary="true" item="Transformation Applied (warn-text)" x:for-anchor=""/>
1864<t>
1865   This Warning code &MUST; be added by a proxy if it applies any transformation to the
1866   representation, such as changing the content-coding, media-type, or
1867   modifying the representation data, unless this Warning code already appears
1868   in the response.
1869</t>
1870</section>
1871
1872<section title='Warning: 299 - "Miscellaneous Persistent Warning"' anchor="warn.299">
1873  <iref primary="true" item="299 (warn-code)" x:for-anchor=""/>
1874  <iref primary="true" item="Miscellaneous Persistent Warning (warn-text)" x:for-anchor=""/>
1875<t>
1876   The warning text can include arbitrary information to be presented to
1877   a human user or logged. A system receiving this warning &MUST-NOT; take
1878   any automated action.
1879</t>
1880</section>
1881</section>
1882</section>
1883
1884<section anchor="history.lists" title="History Lists">
1885<t>
1886   User agents often have history mechanisms, such as "Back" buttons and
1887   history lists, that can be used to redisplay a representation retrieved
1888   earlier in a session.
1889</t>
1890<t>
1891   The freshness model (<xref target="expiration.model"/>) does not
1892   necessarily apply to history mechanisms. That is, a history mechanism can
1893   display a previous representation even if it has expired.
1894</t>
1895<t>
1896   This does not prohibit the history mechanism from telling the user that a
1897   view might be stale or from honoring cache directives (e.g.,
1898   Cache-Control: no-store).
1899</t>
1900</section>
1901
1902
1903<section title="IANA Considerations" anchor="iana.considerations">
1904
1905<section title="Cache Directive Registry" anchor="cache.directive.registry">
1906<t>
1907   The "Hypertext Transfer Protocol (HTTP) Cache Directive Registry" defines the namespace for the
1908   cache directives. It has been created and is now maintained at
1909   <eref target="http://www.iana.org/assignments/http-cache-directives"/>.
1910</t>
1911
1912<section title="Procedure" anchor="cache.directive.registry.procedure">
1913<t>
1914   A registration &MUST; include the following fields:
1915   <list style="symbols">
1916      <t>Cache Directive Name</t>
1917      <t>Pointer to specification text</t>
1918   </list>
1919</t>
1920<t>
1921   Values to be added to this namespace require IETF Review (see <xref
1922   target="RFC5226" x:fmt="," x:sec="4.1"/>).
1923</t>
1924</section>
1925
1926<section title="Considerations for New Cache Control Directives" anchor="cache.directive.considerations">
1927<t>
1928   New extension directives ought to consider defining:
1929</t>
1930<t>
1931   <list style="symbols">
1932      <t>What it means for a directive to be specified multiple times,</t>
1933      <t>When the directive does not take an argument, what it means when an
1934      argument is present,</t>
1935      <t>When the directive requires an argument, what it means when it is
1936      missing,</t>
1937      <t>Whether the directive is specific to requests, responses, or able
1938        to be used in either.</t>
1939   </list>
1940</t>
1941<t>
1942  See also <xref target="cache.control.extensions"/>.
1943</t>
1944</section>
1945
1946<section title="Registrations" anchor="cache.directive.registration">
1947<t>
1948  The registry has been populated with the registrations below:
1949</t>
1950<?BEGININC p6-cache.cache-directives ?>
1951<!--AUTOGENERATED FROM extract-cache-directives-defs.xslt, do not edit manually-->
1952<texttable xmlns:my="#my" align="left" suppress-title="true"
1953           anchor="iana.cache.directive.registration.table">
1954   <ttcol>Cache Directive</ttcol>
1955   <ttcol>Reference</ttcol>
1956
1957   <c>max-age</c>
1958   <c>
1959      <xref target="cache-request-directive.max-age"/>, <xref target="cache-response-directive.max-age"/>
1960   </c>
1961   <c>max-stale</c>
1962   <c>
1963      <xref target="cache-request-directive.max-stale"/>
1964   </c>
1965   <c>min-fresh</c>
1966   <c>
1967      <xref target="cache-request-directive.min-fresh"/>
1968   </c>
1969   <c>must-revalidate</c>
1970   <c>
1971      <xref target="cache-response-directive.must-revalidate"/>
1972   </c>
1973   <c>no-cache</c>
1974   <c>
1975      <xref target="cache-request-directive.no-cache"/>, <xref target="cache-response-directive.no-cache"/>
1976   </c>
1977   <c>no-store</c>
1978   <c>
1979      <xref target="cache-request-directive.no-store"/>, <xref target="cache-response-directive.no-store"/>
1980   </c>
1981   <c>no-transform</c>
1982   <c>
1983      <xref target="cache-request-directive.no-transform"/>, <xref target="cache-response-directive.no-transform"/>
1984   </c>
1985   <c>only-if-cached</c>
1986   <c>
1987      <xref target="cache-request-directive.only-if-cached"/>
1988   </c>
1989   <c>private</c>
1990   <c>
1991      <xref target="cache-response-directive.private"/>
1992   </c>
1993   <c>proxy-revalidate</c>
1994   <c>
1995      <xref target="cache-response-directive.proxy-revalidate"/>
1996   </c>
1997   <c>public</c>
1998   <c>
1999      <xref target="cache-response-directive.public"/>
2000   </c>
2001   <c>s-maxage</c>
2002   <c>
2003      <xref target="cache-response-directive.s-maxage"/>
2004   </c>
2005   <c>stale-if-error</c>
2006   <c>
2007      <xref xmlns:x="http://purl.org/net/xml2rfc/ext" target="RFC5861" x:fmt="," x:sec="4"/>
2008   </c>
2009   <c>stale-while-revalidate</c>
2010   <c>
2011      <xref xmlns:x="http://purl.org/net/xml2rfc/ext" target="RFC5861" x:fmt="," x:sec="3"/>
2012   </c>
2013</texttable>
2014<!--(END)-->
2015<?ENDINC p6-cache.cache-directives ?>
2016</section>
2017</section>
2018
2019<section title="Warn Code Registry" anchor="warn.code.registry">
2020<t>
2021   The "Hypertext Transfer Protocol (HTTP) Warn Codes" registry defines the namespace for warn codes.
2022   It has been created and is now maintained at
2023   <eref target="http://www.iana.org/assignments/http-warn-codes"/>.
2024</t>
2025
2026<section title="Procedure" anchor="warn.code.registry.procedure">
2027<t>
2028   A registration &MUST; include the following fields:
2029   <list style="symbols">
2030      <t>Warn Code (3 digits)</t>
2031      <t>Short Description</t>
2032      <t>Pointer to specification text</t>
2033   </list>
2034</t>
2035<t>
2036   Values to be added to this namespace require IETF Review (see <xref
2037   target="RFC5226" x:fmt="," x:sec="4.1"/>).
2038</t>
2039</section>
2040
2041<section title="Registrations" anchor="warn.code.registration">
2042<t>
2043  The registry has been populated with the registrations below:
2044</t>
2045<?BEGININC p6-cache.iana-warn-codes ?>
2046<!--AUTOGENERATED FROM extract-warn-code-defs.xslt, do not edit manually-->
2047<texttable align="left" suppress-title="true" anchor="iana.warn.code.registration.table">
2048   <ttcol>Warn Code</ttcol>
2049   <ttcol>Short Description</ttcol>
2050   <ttcol>Reference</ttcol>
2051   <c>110</c>
2052   <c>Response is Stale</c>
2053   <c>
2054      <xref target="warn.110"/>
2055   </c>
2056   <c>111</c>
2057   <c>Revalidation Failed</c>
2058   <c>
2059      <xref target="warn.111"/>
2060   </c>
2061   <c>112</c>
2062   <c>Disconnected Operation</c>
2063   <c>
2064      <xref target="warn.112"/>
2065   </c>
2066   <c>113</c>
2067   <c>Heuristic Expiration</c>
2068   <c>
2069      <xref target="warn.113"/>
2070   </c>
2071   <c>199</c>
2072   <c>Miscellaneous Warning</c>
2073   <c>
2074      <xref target="warn.199"/>
2075   </c>
2076   <c>214</c>
2077   <c>Transformation Applied</c>
2078   <c>
2079      <xref target="warn.214"/>
2080   </c>
2081   <c>299</c>
2082   <c>Miscellaneous Persistent Warning</c>
2083   <c>
2084      <xref target="warn.299"/>
2085   </c>
2086</texttable>
2087<!--(END)-->
2088<?ENDINC p6-cache.iana-warn-codes ?>
2089</section>
2090</section>
2091
2092<section title="Header Field Registration" anchor="header.field.registration">
2093<t>
2094   HTTP header fields are registered within the "Message Headers" registry
2095   maintained at
2096   <eref target="http://www.iana.org/assignments/message-headers/"/>.
2097</t>
2098<t>
2099   This document defines the following HTTP header fields, so the
2100   "Permanent Message Header Field Names" registry has been updated
2101   accordingly (see <xref target="BCP90"/>).
2102</t>
2103<?BEGININC p6-cache.iana-headers ?>
2104<!--AUTOGENERATED FROM extract-header-defs.xslt, do not edit manually-->
2105<texttable align="left" suppress-title="true" anchor="iana.header.registration.table">
2106   <ttcol>Header Field Name</ttcol>
2107   <ttcol>Protocol</ttcol>
2108   <ttcol>Status</ttcol>
2109   <ttcol>Reference</ttcol>
2110
2111   <c>Age</c>
2112   <c>http</c>
2113   <c>standard</c>
2114   <c>
2115      <xref target="header.age"/>
2116   </c>
2117   <c>Cache-Control</c>
2118   <c>http</c>
2119   <c>standard</c>
2120   <c>
2121      <xref target="header.cache-control"/>
2122   </c>
2123   <c>Expires</c>
2124   <c>http</c>
2125   <c>standard</c>
2126   <c>
2127      <xref target="header.expires"/>
2128   </c>
2129   <c>Pragma</c>
2130   <c>http</c>
2131   <c>standard</c>
2132   <c>
2133      <xref target="header.pragma"/>
2134   </c>
2135   <c>Warning</c>
2136   <c>http</c>
2137   <c>standard</c>
2138   <c>
2139      <xref target="header.warning"/>
2140   </c>
2141</texttable>
2142<!--(END)-->
2143<?ENDINC p6-cache.iana-headers ?>
2144<t>
2145   The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task
2146   Force".
2147</t>
2148</section>
2149</section>
2150
2151<section anchor="security.considerations" title="Security Considerations">
2152<t>
2153   This section is meant to inform developers, information providers, and
2154   users of known security concerns specific to HTTP caching.
2155   More general security considerations are addressed in HTTP messaging
2156   &messaging; and semantics &semantics;.
2157</t>
2158<t>
2159   Caches expose additional potential vulnerabilities, since the contents of
2160   the cache represent an attractive target for malicious exploitation.
2161   Because cache contents persist after an HTTP request is complete, an attack
2162   on the cache can reveal information long after a user believes that the
2163   information has been removed from the network. Therefore, cache contents
2164   need to be protected as sensitive information.
2165</t>
2166<t>
2167   In particular, various attacks might be amplified by being stored in a
2168   shared cache; such "cache poisoning" attacks use the cache to distribute a
2169   malicious payload to many clients, and are especially effective when an
2170   attacker can use implementation flaws, elevated privileges, or other
2171   techniques to insert such a response into a cache. One common attack vector
2172   for cache poisoning is to exploit differences in message parsing on proxies
2173   and in user agents; see &body.length; for the relevant requirements.
2174</t>
2175<t>
2176   Likewise, implementation flaws (as well as misunderstanding of cache
2177   operation) might lead to caching of sensitive information (e.g.,
2178   authentication credentials) that is thought to be private, exposing it to
2179   unauthorized parties.
2180</t>
2181<t>
2182   Furthermore, the very use of a cache can bring about privacy concerns. For
2183   example, if two users share a cache, and the first one browses to a site,
2184   the second may be able to detect that the other has been to that site,
2185   because the resources from it load more quickly, thanks to the cache.
2186</t>
2187<t>
2188   Note that the Set-Cookie response header field <xref target="RFC6265"/> does not
2189   inhibit caching; a cacheable response with a Set-Cookie header field can be (and
2190   often is) used to satisfy subsequent requests to caches. Servers who wish
2191   to control caching of these responses are encouraged to emit appropriate
2192   Cache-Control response header fields.
2193</t>
2194
2195</section>
2196
2197<section title="Acknowledgments" anchor="acks">
2198<t>
2199  See &acks;.
2200</t>
2201</section>
2202
2203</middle>
2204
2205<back>
2206<references title="Normative References">
2207
2208  <reference anchor="RFC7230">
2209    <front>
2210      <title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title>
2211      <author fullname="Roy T. Fielding" initials="R." role="editor" surname="Fielding">
2212        <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
2213        <address><email>fielding@gbiv.com</email></address>
2214      </author>
2215      <author fullname="Julian F. Reschke" initials="J. F." role="editor" surname="Reschke">
2216        <organization abbrev="greenbytes">greenbytes GmbH</organization>
2217        <address><email>julian.reschke@greenbytes.de</email></address>
2218      </author>
2219      <date month="&ID-MONTH;" year="&ID-YEAR;" />
2220    </front>
2221    <seriesInfo name="RFC" value="7230"/>
2222    <x:source basename="p1-messaging" href="p1-messaging.xml">
2223      <x:defines>Content-Length</x:defines>
2224      <x:defines>Via</x:defines>
2225    </x:source>
2226  </reference>
2227
2228  <reference anchor="RFC7231">
2229    <front>
2230      <title>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</title>
2231      <author fullname="Roy T. Fielding" initials="R." role="editor" surname="Fielding">
2232        <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
2233        <address><email>fielding@gbiv.com</email></address>
2234      </author>
2235      <author fullname="Julian F. Reschke" initials="J. F." role="editor" surname="Reschke">
2236        <organization abbrev="greenbytes">greenbytes GmbH</organization>
2237        <address><email>julian.reschke@greenbytes.de</email></address>
2238      </author>
2239      <date month="&ID-MONTH;" year="&ID-YEAR;" />
2240    </front>
2241    <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p2-semantics-&ID-VERSION;" />
2242    <x:source basename="p2-semantics" href="p2-semantics.xml">
2243      <x:defines>2xx (Successful)</x:defines>
2244      <x:defines>200 (OK)</x:defines>
2245      <x:defines>203 (Non-Authoritative Information)</x:defines>
2246      <x:defines>3xx (Redirection)</x:defines>
2247      <x:defines>300 (Multiple Choices)</x:defines>
2248      <x:defines>301 (Moved Permanently)</x:defines>
2249      <x:defines>404 (Not Found)</x:defines>
2250      <x:defines>410 (Gone)</x:defines>
2251      <x:defines>5xx (Server Error)</x:defines>
2252      <x:defines>504 (Gateway Timeout)</x:defines>
2253      <x:defines>Accept</x:defines>
2254      <x:defines>Content-Encoding</x:defines>
2255      <x:defines>Content-Location</x:defines>
2256      <x:defines>Content-Type</x:defines>
2257      <x:defines>Date</x:defines>
2258      <x:defines>Location</x:defines>
2259      <x:defines>Vary</x:defines>
2260    </x:source>
2261  </reference>
2262
2263  <reference anchor="RFC7232">
2264    <front>
2265      <title>Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests</title>
2266      <author fullname="Roy T. Fielding" initials="R." role="editor" surname="Fielding">
2267        <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
2268        <address><email>fielding@gbiv.com</email></address>
2269      </author>
2270      <author fullname="Julian F. Reschke" initials="J. F." role="editor" surname="Reschke">
2271        <organization abbrev="greenbytes">greenbytes GmbH</organization>
2272        <address><email>julian.reschke@greenbytes.de</email></address>
2273      </author>
2274      <date month="&ID-MONTH;" year="&ID-YEAR;" />
2275    </front>
2276    <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p4-conditional-&ID-VERSION;" />
2277    <x:source basename="p4-conditional" href="p4-conditional.xml">
2278      <x:defines>304</x:defines>
2279      <x:defines>304 (Not Modified)</x:defines>
2280      <x:defines>412 (Precondition Failed)</x:defines>
2281      <x:defines>ETag</x:defines>
2282      <x:defines>If-Modified-Since</x:defines>
2283      <x:defines>If-Unmodified-Since</x:defines>
2284      <x:defines>If-Match</x:defines>
2285      <x:defines>If-None-Match</x:defines>
2286      <x:defines>Last-Modified</x:defines>
2287    </x:source>
2288  </reference>
2289
2290  <reference anchor="RFC7233">
2291    <front>
2292      <title>Hypertext Transfer Protocol (HTTP/1.1): Range Requests</title>
2293      <author fullname="Roy T. Fielding" initials="R." role="editor" surname="Fielding">
2294        <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
2295        <address><email>fielding@gbiv.com</email></address>
2296      </author>
2297      <author fullname="Yves Lafon" initials="Y." role="editor" surname="Lafon">
2298        <organization abbrev="W3C">World Wide Web Consortium</organization>
2299        <address><email>ylafon@w3.org</email></address>
2300      </author>
2301      <author fullname="Julian F. Reschke" initials="J. F." role="editor" surname="Reschke">
2302        <organization abbrev="greenbytes">greenbytes GmbH</organization>
2303        <address><email>julian.reschke@greenbytes.de</email></address>
2304      </author>
2305      <date month="&ID-MONTH;" year="&ID-YEAR;" />
2306    </front>
2307    <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p5-range-&ID-VERSION;" />
2308    <x:source basename="p5-range" href="p5-range.xml">
2309      <x:defines>206 (Partial Content)</x:defines>
2310      <x:defines>Content-Range</x:defines>
2311      <x:defines>If-Range</x:defines>
2312      <x:defines>Range</x:defines>
2313    </x:source>
2314  </reference>
2315
2316  <reference anchor="RFC7235">
2317    <front>
2318      <title>Hypertext Transfer Protocol (HTTP/1.1): Authentication</title>
2319      <author fullname="Roy T. Fielding" initials="R." role="editor" surname="Fielding">
2320        <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
2321        <address><email>fielding@gbiv.com</email></address>
2322      </author>
2323      <author fullname="Julian F. Reschke" initials="J. F." role="editor" surname="Reschke">
2324        <organization abbrev="greenbytes">greenbytes GmbH</organization>
2325        <address><email>julian.reschke@greenbytes.de</email></address>
2326      </author>
2327      <date month="&ID-MONTH;" year="&ID-YEAR;" />
2328    </front>
2329    <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p7-auth-&ID-VERSION;" />
2330    <x:source basename="p7-auth" href="p7-auth.xml">
2331      <x:defines>Authorization</x:defines>
2332    </x:source>
2333  </reference>
2334
2335  <reference anchor="RFC2119">
2336    <front>
2337      <title>Key words for use in RFCs to Indicate Requirement Levels</title>
2338      <author fullname="Scott Bradner" initials="S." surname="Bradner">
2339        <organization>Harvard University</organization>
2340        <address><email>sob@harvard.edu</email></address>
2341      </author>
2342      <date month="March" year="1997" />
2343    </front>
2344    <seriesInfo name="BCP" value="14" />
2345    <seriesInfo name="RFC" value="2119" />
2346  </reference>
2347
2348  <reference anchor="RFC5234">
2349    <front>
2350      <title abbrev="ABNF for Syntax Specifications">Augmented BNF for Syntax Specifications: ABNF</title>
2351      <author initials="D." surname="Crocker" fullname="Dave Crocker" role="editor">
2352        <organization>Brandenburg InternetWorking</organization>
2353        <address>
2354          <email>dcrocker@bbiw.net</email>
2355        </address> 
2356      </author>
2357      <author initials="P." surname="Overell" fullname="Paul Overell">
2358        <organization>THUS plc.</organization>
2359        <address>
2360          <email>paul.overell@thus.net</email>
2361        </address>
2362      </author>
2363      <date month="January" year="2008"/>
2364    </front>
2365    <seriesInfo name="STD" value="68"/>
2366    <seriesInfo name="RFC" value="5234"/>
2367  </reference>
2368 
2369</references>
2370
2371<references title="Informative References">
2372
2373  <reference anchor="RFC2616">
2374    <front>
2375      <title>Hypertext Transfer Protocol -- HTTP/1.1</title>
2376      <author fullname="R. Fielding" initials="R." surname="Fielding">
2377        <organization>University of California, Irvine</organization>
2378        <address><email>fielding@ics.uci.edu</email></address>
2379      </author>
2380      <author fullname="J. Gettys" initials="J." surname="Gettys">
2381        <organization>W3C</organization>
2382        <address><email>jg@w3.org</email></address>
2383      </author>
2384      <author fullname="J. Mogul" initials="J." surname="Mogul">
2385        <organization>Compaq Computer Corporation</organization>
2386        <address><email>mogul@wrl.dec.com</email></address>
2387      </author>
2388      <author fullname="H. Frystyk" initials="H." surname="Frystyk">
2389        <organization>MIT Laboratory for Computer Science</organization>
2390        <address><email>frystyk@w3.org</email></address>
2391      </author>
2392      <author fullname="L. Masinter" initials="L." surname="Masinter">
2393        <organization>Xerox Corporation</organization>
2394        <address><email>masinter@parc.xerox.com</email></address>
2395      </author>
2396      <author fullname="P. Leach" initials="P." surname="Leach">
2397        <organization>Microsoft Corporation</organization>
2398        <address><email>paulle@microsoft.com</email></address>
2399      </author>
2400      <author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee">
2401        <organization>W3C</organization>
2402        <address><email>timbl@w3.org</email></address>
2403      </author>
2404      <date month="June" year="1999" />
2405    </front>
2406    <seriesInfo name="RFC" value="2616" />
2407  </reference>
2408
2409  <reference anchor="BCP90">
2410    <front>
2411      <title>Registration Procedures for Message Header Fields</title>
2412      <author fullname="G. Klyne" initials="G." surname="Klyne">
2413        <organization>Nine by Nine</organization>
2414        <address><email>GK-IETF@ninebynine.org</email></address>
2415      </author>
2416      <author fullname="M. Nottingham" initials="M." surname="Nottingham">
2417        <organization>BEA Systems</organization>
2418        <address><email>mnot@pobox.com</email></address>
2419      </author>
2420      <author fullname="J. Mogul" initials="J." surname="Mogul">
2421        <organization>HP Labs</organization>
2422        <address><email>JeffMogul@acm.org</email></address>
2423      </author>
2424      <date month="September" year="2004" />
2425    </front>
2426    <seriesInfo name="BCP" value="90" />
2427    <seriesInfo name="RFC" value="3864" />
2428  </reference>
2429
2430  <reference anchor='RFC5226'>
2431    <front>
2432      <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
2433      <author initials='T.' surname='Narten' fullname='T. Narten'>
2434        <organization>IBM</organization>
2435        <address><email>narten@us.ibm.com</email></address>
2436      </author>
2437      <author initials='H.' surname='Alvestrand' fullname='H. Alvestrand'>
2438        <organization>Google</organization>
2439        <address><email>Harald@Alvestrand.no</email></address>
2440      </author>
2441      <date year='2008' month='May' />
2442    </front>
2443    <seriesInfo name='BCP' value='26' />
2444    <seriesInfo name='RFC' value='5226' />
2445  </reference>
2446
2447  <reference anchor='RFC5861'>
2448    <front>
2449      <title abbrev="HTTP stale controls">HTTP Cache-Control Extensions for Stale Content</title>
2450      <author initials="M." surname="Nottingham" fullname="Mark Nottingham">
2451        <organization>Yahoo! Inc.</organization>
2452        <address><email>mnot@yahoo-inc.com</email></address>
2453      </author>
2454      <date month="April" year="2010"/>
2455    </front>
2456    <seriesInfo name='RFC' value='5861' />
2457  </reference>
2458
2459  <reference anchor='RFC5905'>
2460    <front>
2461      <title>Network Time Protocol Version 4: Protocol and Algorithms Specification</title>
2462      <author initials='D.' surname='Mills' fullname='David L. Mills'/>
2463      <author initials='J.' surname='Martin' fullname='Jim Martin' role="editor"/>
2464      <author initials='J.' surname='Burbank' fullname='Jack Burbank'/>
2465      <author initials='W.' surname='Kasch' fullname='William Kasch'/>
2466      <date year='2010' month='June' />
2467    </front>
2468    <seriesInfo name='RFC' value='5905' />
2469  </reference>
2470
2471  <reference anchor="RFC6265">
2472    <front>
2473      <title>HTTP State Management Mechanism</title>
2474      <author initials="A." surname="Barth" fullname="Adam Barth">
2475        <organization abbrev="U.C. Berkeley">
2476          University of California, Berkeley
2477        </organization>
2478        <address><email>abarth@eecs.berkeley.edu</email></address>
2479      </author>
2480      <date year="2011" month="April" />
2481    </front>
2482    <seriesInfo name="RFC" value="6265"/>
2483  </reference>
2484
2485</references>
2486
2487<section anchor="changes.from.rfc.2616" title="Changes from RFC 2616">
2488<t>
2489  The specification has been substantially rewritten for clarity.
2490</t>
2491<t>
2492  The conditions under which an authenticated response can be cached have been
2493  clarified.
2494  (<xref target="caching.authenticated.responses" />)
2495</t>
2496<t>
2497  New status codes can now define that caches are allowed to use heuristic
2498  freshness with them.
2499  Caches are now allowed to calculate heuristic freshness for URIs with query
2500  components.
2501  (<xref target="heuristic.freshness" />)
2502</t>
2503<t>
2504  The algorithm for calculating age is now less conservative.
2505  Caches are now required to handle dates with time zones as if they're
2506  invalid, because it's not possible to accurately guess.
2507  (<xref target="age.calculations"/>)
2508</t>
2509<t>
2510  The <x:ref>Content-Location</x:ref> response header field is no longer used
2511  to determine the appropriate response to use when validating.
2512  (<xref target="validation.model" />)
2513</t>
2514<t>
2515  The algorithm for selecting a cached negotiated response to use has been
2516  clarified in several ways. In particular, it now explicitly allows
2517  header-specific canonicalization when processing selecting header fields.
2518  (<xref target="caching.negotiated.responses" />)
2519</t>
2520<t>
2521  Requirements regarding denial-of-service attack avoidance when performing
2522  invalidation have been clarified.
2523  (<xref target="invalidation" />)
2524</t>
2525<t>
2526  Cache invalidation only occurs when a successful response is received.
2527  (<xref target="invalidation" />)
2528</t>
2529<t>
2530  Cache directives are explicitly defined to be case-insensitive.
2531  Handling of multiple instances of cache directives when only one is
2532  expected is now defined.
2533  (<xref target="header.cache-control" />)
2534</t>
2535<t>
2536  The "no-store" request directive doesn't apply to responses; i.e.,
2537  a cache can satisfy a request with no-store on it and does not invalidate
2538  it.
2539  (<xref target="cache-request-directive.no-store" />)
2540</t>
2541<t>
2542  The qualified forms of the private and no-cache cache directives are noted
2543  to not be widely implemented; for example, "private=foo" is interpreted by many
2544  caches as simply "private". Additionally, the meaning of the qualified
2545  form of no-cache has been clarified.
2546  (<xref target="cache-response-directive" />)
2547</t>
2548<t>
2549  The "no-cache" response directive's meaning has been clarified.
2550  (<xref target="cache-response-directive.no-cache" />)
2551</t>
2552<t>
2553  The one-year limit on <x:ref>Expires</x:ref> header field values has been removed; instead,
2554  the reasoning for using a sensible value is given.
2555  (<xref target="header.expires" />)
2556</t>
2557<t>
2558  The <x:ref>Pragma</x:ref> header field is now only defined for backwards compatibility;
2559  future pragmas are deprecated.
2560  (<xref target="header.pragma" />)
2561</t>
2562<t>
2563  Some requirements regarding production and processing of the <x:ref>Warning</x:ref> 
2564  header fields have been relaxed, as it is not widely implemented.
2565  Furthermore, the <x:ref>Warning</x:ref> header field no longer uses RFC 2047 encoding,
2566  nor does it allow multiple languages, as these aspects were not implemented.
2567  (<xref target="header.warning" />)
2568</t>
2569<t>
2570  This specification introduces the Cache Directive and Warn Code Registries,
2571  and defines considerations for new cache directives.
2572  (<xref target="cache.directive.registry"/> and <xref target="warn.code.registry"/>)
2573</t>
2574</section>
2575
2576<section title="Imported ABNF" anchor="imported.abnf">
2577   <x:anchor-alias value="ALPHA"/>
2578   <x:anchor-alias value="CR"/>
2579   <x:anchor-alias value="DIGIT"/>
2580   <x:anchor-alias value="DQUOTE"/>
2581   <x:anchor-alias value="LF"/>
2582   <x:anchor-alias value="OCTET"/>
2583   <x:anchor-alias value="SP"/>
2584   <x:anchor-alias value="VCHAR"/>
2585   <x:anchor-alias value="quoted-string"/>
2586   <x:anchor-alias value="token"/>
2587   <x:anchor-alias value="OWS"/>
2588   <x:anchor-alias value="field-name"/>
2589   <x:anchor-alias value="HTTP-date"/>
2590   <x:anchor-alias value="port"/>
2591   <x:anchor-alias value="pseudonym"/>
2592   <x:anchor-alias value="uri-host"/>
2593<t>
2594   The following core rules are included by reference, as defined in <xref
2595   target="RFC5234" x:fmt="of" x:sec="B.1"/>: ALPHA (letters), CR (carriage
2596   return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double
2597   quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit
2598   sequence of data), SP (space), and VCHAR (any visible US-ASCII character).
2599</t>
2600<t>
2601   The rules below are defined in <xref target="RFC7230"/>:
2602</t>
2603<figure><artwork type="abnf2616">
2604  <x:ref>OWS</x:ref>           = &lt;OWS, see &whitespace;&gt;
2605  <x:ref>field-name</x:ref>    = &lt;field-name, see &header-fields;&gt;
2606  <x:ref>quoted-string</x:ref> = &lt;quoted-string, see &field-components;&gt;
2607  <x:ref>token</x:ref>         = &lt;token, see &field-components;&gt;
2608
2609  <x:ref>port</x:ref>          = &lt;port, see &uri;&gt;
2610  <x:ref>pseudonym</x:ref>     = &lt;pseudonym, see &header-via;&gt; 
2611  <x:ref>uri-host</x:ref>      = &lt;uri-host, see &uri;&gt;
2612</artwork></figure>
2613<t>
2614   The rules below are defined in other parts:
2615</t>
2616<figure><artwork type="abnf2616">
2617  <x:ref>HTTP-date</x:ref>     = &lt;HTTP-date, see &http-date;&gt;
2618</artwork></figure>
2619</section>
2620
2621<?BEGININC p6-cache.abnf-appendix ?>
2622<section xmlns:x="http://purl.org/net/xml2rfc/ext" title="Collected ABNF" anchor="collected.abnf">
2623<t>
2624  In the collected ABNF below, list rules are expanded as per <xref target="RFC7230" x:rel="#notation"/>.
2625</t><figure>
2626<artwork type="abnf" name="p6-cache.parsed-abnf">
2627<x:ref>Age</x:ref> = delta-seconds
2628
2629<x:ref>Cache-Control</x:ref> = *( "," OWS ) cache-directive *( OWS "," [ OWS
2630 cache-directive ] )
2631
2632<x:ref>Expires</x:ref> = HTTP-date
2633
2634<x:ref>HTTP-date</x:ref> = &lt;HTTP-date, see [RFC7231], Section 7.1.1.1&gt;
2635
2636<x:ref>OWS</x:ref> = &lt;OWS, see [RFC7230], Section 3.2.3&gt;
2637
2638<x:ref>Pragma</x:ref> = *( "," OWS ) pragma-directive *( OWS "," [ OWS
2639 pragma-directive ] )
2640
2641<x:ref>Warning</x:ref> = *( "," OWS ) warning-value *( OWS "," [ OWS warning-value ]
2642 )
2643
2644<x:ref>cache-directive</x:ref> = token [ "=" ( token / quoted-string ) ]
2645
2646<x:ref>delta-seconds</x:ref> = 1*DIGIT
2647
2648<x:ref>extension-pragma</x:ref> = token [ "=" ( token / quoted-string ) ]
2649
2650<x:ref>field-name</x:ref> = &lt;field-name, see [RFC7230], Section 3.2&gt;
2651
2652<x:ref>port</x:ref> = &lt;port, see [RFC7230], Section 2.7&gt;
2653<x:ref>pragma-directive</x:ref> = "no-cache" / extension-pragma
2654<x:ref>pseudonym</x:ref> = &lt;pseudonym, see [RFC7230], Section 5.7.1&gt;
2655
2656<x:ref>quoted-string</x:ref> = &lt;quoted-string, see [RFC7230], Section 3.2.6&gt;
2657
2658<x:ref>token</x:ref> = &lt;token, see [RFC7230], Section 3.2.6&gt;
2659
2660<x:ref>uri-host</x:ref> = &lt;uri-host, see [RFC7230], Section 2.7&gt;
2661
2662<x:ref>warn-agent</x:ref> = ( uri-host [ ":" port ] ) / pseudonym
2663<x:ref>warn-code</x:ref> = 3DIGIT
2664<x:ref>warn-date</x:ref> = DQUOTE HTTP-date DQUOTE
2665<x:ref>warn-text</x:ref> = quoted-string
2666<x:ref>warning-value</x:ref> = warn-code SP warn-agent SP warn-text [ SP warn-date
2667 ]
2668</artwork>
2669</figure>
2670</section>
2671<?ENDINC p6-cache.abnf-appendix ?>
2672</back>
2673</rfc>
Note: See TracBrowser for help on using the repository browser.