source: draft-ietf-httpbis/16/draft-ietf-httpbis-p6-cache-16.txt @ 1831

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

prepare for publication of -16 on Aug 24.

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