source: draft-ietf-httpbis/18/draft-ietf-httpbis-p6-cache-18.txt @ 1860

Last change on this file since 1860 was 1499, checked in by julian.reschke@…, 9 years ago

prepare for publication of -18 on Jan 04.

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