source: draft-ietf-httpbis/10/p6-cache.xml @ 945

Last change on this file since 945 was 945, checked in by mnot@…, 9 years ago

reformat xml

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