source: draft-ietf-httpbis/20/draft-ietf-httpbis-p6-cache-20.txt @ 1809

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

Remove mentions of "seven" parts.

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