source: draft-ietf-httpbis/20/draft-ietf-httpbis-p6-cache-20.xml @ 1807

Last change on this file since 1807 was 1807, checked in by julian.reschke@…, 8 years ago

Prepare release of -20 drafts

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