draft-ietf-httpbis-p6-cache-12.txt   draft-ietf-httpbis-p6-cache-13.txt 
HTTPbis Working Group R. Fielding, Ed. HTTPbis Working Group R. Fielding, Ed.
Internet-Draft Day Software Internet-Draft Adobe
Obsoletes: 2616 (if approved) J. Gettys Obsoletes: 2616 (if approved) J. Gettys
Intended status: Standards Track Alcatel-Lucent Intended status: Standards Track Alcatel-Lucent
Expires: April 28, 2011 J. Mogul Expires: September 15, 2011 J. Mogul
HP HP
H. Frystyk H. Frystyk
Microsoft Microsoft
L. Masinter L. Masinter
Adobe Systems Adobe
P. Leach P. Leach
Microsoft Microsoft
T. Berners-Lee T. Berners-Lee
W3C/MIT W3C/MIT
Y. Lafon, Ed. Y. Lafon, Ed.
W3C W3C
M. Nottingham, Ed. M. Nottingham, Ed.
J. Reschke, Ed. J. Reschke, Ed.
greenbytes greenbytes
October 25, 2010 March 14, 2011
HTTP/1.1, part 6: Caching HTTP/1.1, part 6: Caching
draft-ietf-httpbis-p6-cache-12 draft-ietf-httpbis-p6-cache-13
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is an application-level The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information protocol for distributed, collaborative, hypermedia information
systems. This document is Part 6 of the seven-part specification systems. This document is Part 6 of the seven-part specification
that defines the protocol referred to as "HTTP/1.1" and, taken that defines the protocol referred to as "HTTP/1.1" and, taken
together, obsoletes RFC 2616. Part 6 defines requirements on HTTP together, obsoletes RFC 2616. Part 6 defines requirements on HTTP
caches and the associated header fields that control cache behavior caches and the associated header fields that control cache behavior
or indicate cacheable response messages. or indicate cacheable response messages.
Editorial Note (To be removed by RFC Editor) Editorial Note (To be removed by RFC Editor)
Discussion of this draft should take place on the HTTPBIS working Discussion of this draft should take place on the HTTPBIS working
group mailing list (ietf-http-wg@w3.org). The current issues list is group mailing list (ietf-http-wg@w3.org). The current issues list is
at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
documents (including fancy diffs) can be found at documents (including fancy diffs) can be found at
<http://tools.ietf.org/wg/httpbis/>. <http://tools.ietf.org/wg/httpbis/>.
The changes in this draft are summarized in Appendix C.13. The changes in this draft are summarized in Appendix C.14.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 28, 2011. This Internet-Draft will expire on September 15, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 51 skipping to change at page 2, line 51
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7
1.4. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7 1.4. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7
1.4.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 7 1.4.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 7
1.4.2. ABNF Rules defined in other Parts of the 1.4.2. ABNF Rules defined in other Parts of the
Specification . . . . . . . . . . . . . . . . . . . . 7 Specification . . . . . . . . . . . . . . . . . . . . 7
2. Cache Operation . . . . . . . . . . . . . . . . . . . . . . . 7 2. Cache Operation . . . . . . . . . . . . . . . . . . . . . . . 8
2.1. Response Cacheability . . . . . . . . . . . . . . . . . . 7 2.1. Response Cacheability . . . . . . . . . . . . . . . . . . 8
2.1.1. Storing Partial and Incomplete Responses . . . . . . . 8 2.1.1. Storing Partial and Incomplete Responses . . . . . . . 9
2.2. Constructing Responses from Caches . . . . . . . . . . . . 9 2.2. Constructing Responses from Caches . . . . . . . . . . . . 9
2.3. Freshness Model . . . . . . . . . . . . . . . . . . . . . 10 2.3. Freshness Model . . . . . . . . . . . . . . . . . . . . . 10
2.3.1. Calculating Freshness Lifetime . . . . . . . . . . . . 11 2.3.1. Calculating Freshness Lifetime . . . . . . . . . . . . 11
2.3.2. Calculating Age . . . . . . . . . . . . . . . . . . . 12 2.3.2. Calculating Age . . . . . . . . . . . . . . . . . . . 12
2.3.3. Serving Stale Responses . . . . . . . . . . . . . . . 13 2.3.3. Serving Stale Responses . . . . . . . . . . . . . . . 13
2.4. Validation Model . . . . . . . . . . . . . . . . . . . . . 14 2.4. Validation Model . . . . . . . . . . . . . . . . . . . . . 14
2.5. Request Methods that Invalidate . . . . . . . . . . . . . 15 2.5. Request Methods that Invalidate . . . . . . . . . . . . . 15
2.6. Shared Caching of Authenticated Responses . . . . . . . . 15 2.6. Shared Caching of Authenticated Responses . . . . . . . . 15
2.7. Caching Negotiated Responses . . . . . . . . . . . . . . . 16 2.7. Caching Negotiated Responses . . . . . . . . . . . . . . . 16
2.8. Combining Responses . . . . . . . . . . . . . . . . . . . 17 2.8. Combining Responses . . . . . . . . . . . . . . . . . . . 17
3. Header Field Definitions . . . . . . . . . . . . . . . . . . . 17 3. Header Field Definitions . . . . . . . . . . . . . . . . . . . 17
3.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 18 3.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 18
3.2.1. Request Cache-Control Directives . . . . . . . . . . . 19 3.2.1. Request Cache-Control Directives . . . . . . . . . . . 19
3.2.2. Response Cache-Control Directives . . . . . . . . . . 20 3.2.2. Response Cache-Control Directives . . . . . . . . . . 21
3.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 23 3.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 23
3.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.6. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.6. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 26
4. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 29 4. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 29
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
5.1. Cache Directive Registry . . . . . . . . . . . . . . . . . 29 5.1. Cache Directive Registry . . . . . . . . . . . . . . . . . 29
5.2. Header Field Registration . . . . . . . . . . . . . . . . 30 5.2. Header Field Registration . . . . . . . . . . . . . . . . 30
6. Security Considerations . . . . . . . . . . . . . . . . . . . 30 6. Security Considerations . . . . . . . . . . . . . . . . . . . 30
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
8.1. Normative References . . . . . . . . . . . . . . . . . . . 30 8.1. Normative References . . . . . . . . . . . . . . . . . . . 31
8.2. Informative References . . . . . . . . . . . . . . . . . . 31 8.2. Informative References . . . . . . . . . . . . . . . . . . 32
Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 32 Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 32
Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 32 Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 32
Appendix C. Change Log (to be removed by RFC Editor before Appendix C. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 33 publication) . . . . . . . . . . . . . . . . . . . . 34
C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 34 C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 34
C.2. Since draft-ietf-httpbis-p6-cache-00 . . . . . . . . . . . 34 C.2. Since draft-ietf-httpbis-p6-cache-00 . . . . . . . . . . . 34
C.3. Since draft-ietf-httpbis-p6-cache-01 . . . . . . . . . . . 34 C.3. Since draft-ietf-httpbis-p6-cache-01 . . . . . . . . . . . 35
C.4. Since draft-ietf-httpbis-p6-cache-02 . . . . . . . . . . . 35 C.4. Since draft-ietf-httpbis-p6-cache-02 . . . . . . . . . . . 35
C.5. Since draft-ietf-httpbis-p6-cache-03 . . . . . . . . . . . 35 C.5. Since draft-ietf-httpbis-p6-cache-03 . . . . . . . . . . . 35
C.6. Since draft-ietf-httpbis-p6-cache-04 . . . . . . . . . . . 35 C.6. Since draft-ietf-httpbis-p6-cache-04 . . . . . . . . . . . 35
C.7. Since draft-ietf-httpbis-p6-cache-05 . . . . . . . . . . . 35 C.7. Since draft-ietf-httpbis-p6-cache-05 . . . . . . . . . . . 36
C.8. Since draft-ietf-httpbis-p6-cache-06 . . . . . . . . . . . 36 C.8. Since draft-ietf-httpbis-p6-cache-06 . . . . . . . . . . . 36
C.9. Since draft-ietf-httpbis-p6-cache-07 . . . . . . . . . . . 36 C.9. Since draft-ietf-httpbis-p6-cache-07 . . . . . . . . . . . 36
C.10. Since draft-ietf-httpbis-p6-cache-08 . . . . . . . . . . . 36 C.10. Since draft-ietf-httpbis-p6-cache-08 . . . . . . . . . . . 37
C.11. Since draft-ietf-httpbis-p6-cache-09 . . . . . . . . . . . 37 C.11. Since draft-ietf-httpbis-p6-cache-09 . . . . . . . . . . . 37
C.12. Since draft-ietf-httpbis-p6-cache-10 . . . . . . . . . . . 37 C.12. Since draft-ietf-httpbis-p6-cache-10 . . . . . . . . . . . 38
C.13. Since draft-ietf-httpbis-p6-cache-11 . . . . . . . . . . . 38 C.13. Since draft-ietf-httpbis-p6-cache-11 . . . . . . . . . . . 38
C.14. Since draft-ietf-httpbis-p6-cache-12 . . . . . . . . . . . 38
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
HTTP is typically used for distributed information systems, where HTTP is typically used for distributed information systems, where
performance can be improved by the use of response caches. This performance can be improved by the use of response caches. This
document defines aspects of HTTP/1.1 related to caching and reusing document defines aspects of HTTP/1.1 related to caching and reusing
response messages. response messages.
1.1. Purpose 1.1. Purpose
skipping to change at page 5, line 37 skipping to change at page 5, line 37
required, it is often possible to reuse all or parts of the payload required, it is often possible to reuse all or parts of the payload
of a prior response to satisfy the request, thereby reducing network of a prior response to satisfy the request, thereby reducing network
bandwidth usage; a "validation" mechanism is used for this purpose bandwidth usage; a "validation" mechanism is used for this purpose
(see Section 2.4). (see Section 2.4).
1.2. Terminology 1.2. Terminology
This specification uses a number of terms to refer to the roles This specification uses a number of terms to refer to the roles
played by participants in, and objects of, HTTP caching. played by participants in, and objects of, HTTP caching.
cache
A conformant implementation of a HTTP cache. Note that this
implies an HTTP/1.1 cache; this specification does not define
conformance for HTTP/1.0 caches.
shared cache
A cache that is accessible to more than one user; usually (but not
always) deployed as part of an intermediary.
private cache
A cache that is dedicated to a single user.
cacheable cacheable
A response is cacheable if a cache is allowed to store a copy of A response is cacheable if a cache is allowed to store a copy of
the response message for use in answering subsequent requests. the response message for use in answering subsequent requests.
Even when a response is cacheable, there might be additional Even when a response is cacheable, there might be additional
constraints on whether a cache can use the cached copy to satisfy constraints on whether a cache can use the stored copy to satisfy
a particular request. a particular request.
explicit expiration time explicit expiration time
The time at which the origin server intends that a representation The time at which the origin server intends that a representation
no longer be returned by a cache without further validation. no longer be returned by a cache without further validation.
heuristic expiration time heuristic expiration time
An expiration time assigned by a cache when no explicit expiration An expiration time assigned by a cache when no explicit expiration
skipping to change at page 6, line 38 skipping to change at page 6, line 51
lifetime. lifetime.
stale stale
A response is stale if its age has passed its freshness lifetime A response is stale if its age has passed its freshness lifetime
(either explicit or heuristic). (either explicit or heuristic).
validator validator
A protocol element (e.g., an entity-tag or a Last-Modified time) A protocol element (e.g., an entity-tag or a Last-Modified time)
that is used to find out whether a stored response has an that is used to find out whether a stored response is an
equivalent copy of a representation. equivalent copy of a representation.
shared cache
A cache that is accessible to more than one user. A non-shared
cache is dedicated to a single user.
1.3. Requirements 1.3. Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
An implementation is not compliant if it fails to satisfy one or more An implementation is not compliant if it fails to satisfy one or more
of the "MUST" or "REQUIRED" level requirements for the protocols it of the "MUST" or "REQUIRED" level requirements for the protocols it
implements. An implementation that satisfies all the "MUST" or implements. An implementation that satisfies all the "MUST" or
"REQUIRED" level and all the "SHOULD" level requirements for its "REQUIRED" level and all the "SHOULD" level requirements for its
skipping to change at page 9, line 20 skipping to change at page 9, line 30
For a presented request, a cache MUST NOT return a stored response, For a presented request, a cache MUST NOT return a stored response,
unless: unless:
o The presented effective request URI (Section 4.3 of [Part1]) and o The presented effective request URI (Section 4.3 of [Part1]) and
that of the stored response match, and that of the stored response match, and
o the request method associated with the stored response allows it o the request method associated with the stored response allows it
to be used for the presented request, and to be used for the presented request, and
o selecting request-header fields nominated by the stored response o selecting header fields nominated by the stored response (if any)
(if any) match those presented (see Section 2.7), and match those presented (see Section 2.7), and
o the presented request and stored response are free from directives o the presented request and stored response are free from directives
that would prevent its use (see Section 3.2 and Section 3.4), and that would prevent its use (see Section 3.2 and Section 3.4), and
o the stored response is either: o the stored response is either:
* fresh (see Section 2.3), or * fresh (see Section 2.3), or
* allowed to be served stale (see Section 2.3.3), or * allowed to be served stale (see Section 2.3.3), or
* successfully validated (see Section 2.4). * successfully validated (see Section 2.4).
When a stored response is used to satisfy a request without When a stored response is used to satisfy a request without
validation, caches MUST include a single Age header field validation, a cache MUST include a single Age header field
(Section 3.1) in the response with a value equal to the stored (Section 3.1) in the response with a value equal to the stored
response's current_age; see Section 2.3.2. response's current_age; see Section 2.3.2.
Requests with methods that are unsafe (Section 7.1.1 of [Part2]) MUST A cache MUST write through requests with methods that are unsafe
be written through the cache to the origin server; i.e., a cache must (Section 7.1.1 of [Part2]) to the origin server; i.e., a cache must
not reply to such a request before having forwarded the request and not generate a reply to such a request before having forwarded the
having received a corresponding response. request and having received a corresponding response.
Also, note that unsafe requests might invalidate already stored Also, note that unsafe requests might invalidate already stored
responses; see Section 2.5. responses; see Section 2.5.
Caches MUST use the most recent response (as determined by the Date A cache MUST use the most recent response (as determined by the Date
header field) when more than one suitable response is stored. They header field) when more than one suitable response is stored. It can
can also forward a request with "Cache-Control: max-age=0" or "Cache- also forward a request with "Cache-Control: max-age=0" or "Cache-
Control: no-cache" to disambiguate which response to use. Control: no-cache" to disambiguate which response to use.
An HTTP implementation without a clock MUST NOT used stored responses A cache that does not have a clock available MUST NOT used stored
without revalidating them on every use. An HTTP cache, especially a responses without revalidating them on every use. A cache,
shared cache, SHOULD use a mechanism, such as NTP [RFC1305], to especially a shared cache, SHOULD use a mechanism, such as NTP
synchronize its clock with a reliable external standard. [RFC1305], to synchronize its clock with a reliable external
standard.
2.3. Freshness Model 2.3. Freshness Model
When a response is "fresh" in the cache, it can be used to satisfy When a response is "fresh" in the cache, it can be used to satisfy
subsequent requests without contacting the origin server, thereby subsequent requests without contacting the origin server, thereby
improving efficiency. improving efficiency.
The primary mechanism for determining freshness is for an origin The primary mechanism for determining freshness is for an origin
server to provide an explicit expiration time in the future, using server to provide an explicit expiration time in the future, using
either the Expires header field (Section 3.3) or the max-age response either the Expires header field (Section 3.3) or the max-age response
cache directive (Section 3.2.2). Generally, origin servers will cache directive (Section 3.2.2). Generally, origin servers will
assign future explicit expiration times to responses in the belief assign future explicit expiration times to responses in the belief
that the representation is not likely to change in a semantically that the representation is not likely to change in a semantically
significant way before the expiration time is reached. significant way before the expiration time is reached.
If an origin server wishes to force a cache to validate every If an origin server wishes to force a cache to validate every
request, it can assign an explicit expiration time in the past to request, it can assign an explicit expiration time in the past to
indicate that the response is already stale. Compliant caches will indicate that the response is already stale. Compliant caches will
validate the cached response before reusing it for subsequent normally validate the cached response before reusing it for
requests. subsequent requests (see Section 2.3.3).
Since origin servers do not always provide explicit expiration times, Since origin servers do not always provide explicit expiration times,
HTTP caches MAY assign heuristic expiration times when explicit times a cache MAY assign a heuristic expiration time when an explicit time
are not specified, employing algorithms that use other heade field is not specified, employing algorithms that use other header field
values (such as the Last-Modified time) to estimate a plausible values (such as the Last-Modified time) to estimate a plausible
expiration time. The HTTP/1.1 specification does not provide expiration time. This specification does not provide specific
specific algorithms, but does impose worst-case constraints on their algorithms, but does impose worst-case constraints on their results.
results.
The calculation to determine if a response is fresh is: The calculation to determine if a response is fresh is:
response_is_fresh = (freshness_lifetime > current_age) response_is_fresh = (freshness_lifetime > current_age)
The freshness_lifetime is defined in Section 2.3.1; the current_age The freshness_lifetime is defined in Section 2.3.1; the current_age
is defined in Section 2.3.2. is defined in Section 2.3.2.
Additionally, clients might need to influence freshness calculation. Additionally, clients might need to influence freshness calculation.
They can do this using several request cache directives, with the They can do this using several request cache directives, with the
skipping to change at page 11, line 35 skipping to change at page 11, line 44
Section 2.3.1.1. Section 2.3.1.1.
Note that this calculation is not vulnerable to clock skew, since all Note that this calculation is not vulnerable to clock skew, since all
of the information comes from the origin server. of the information comes from the origin server.
2.3.1.1. Calculating Heuristic Freshness 2.3.1.1. Calculating Heuristic Freshness
If no explicit expiration time is present in a stored response that If no explicit expiration time is present in a stored response that
has a status code whose definition allows heuristic freshness to be has a status code whose definition allows heuristic freshness to be
used (including the following in Section 8 of [Part2]: 200, 203, 206, used (including the following in Section 8 of [Part2]: 200, 203, 206,
300, 301 and 410), a heuristic expiration time MAY be calculated. 300, 301 and 410), a cache MAY calculate a heuristic expiration time.
Heuristics MUST NOT be used for response status codes that do not A cache MUST NOT use heuristics to determine freshness for responses
explicitly allow it. with status codes that do not explicitly allow it.
When a heuristic is used to calculate freshness lifetime, the cache When a heuristic is used to calculate freshness lifetime, a cache
SHOULD attach a Warning header field with a 113 warn-code to the SHOULD attach a Warning header field with a 113 warn-code to the
response if its current_age is more than 24 hours and such a warning response if its current_age is more than 24 hours and such a warning
is not already present. is not already present.
Also, if the response has a Last-Modified header field (Section 6.6 Also, if the response has a Last-Modified header field (Section 6.6
of [Part4]), the heuristic expiration value SHOULD be no more than of [Part4]), a cache SHOULD NOT use a heuristic expiration value that
some fraction of the interval since that time. A typical setting of is more than some fraction of the interval since that time. A
this fraction might be 10%. typical setting of this fraction might be 10%.
Note: RFC 2616 ([RFC2616], Section 13.9) required that caches do Note: RFC 2616 ([RFC2616], Section 13.9) required that caches do
not calculate heuristic freshness for URLs with query components not calculate heuristic freshness for URIs with query components
(i.e., those containing '?'). In practice, this has not been (i.e., those containing '?'). In practice, this has not been
widely implemented. Therefore, servers are encouraged to send widely implemented. Therefore, servers are encouraged to send
explicit directives (e.g., Cache-Control: no-cache) if they wish explicit directives (e.g., Cache-Control: no-cache) if they wish
to preclude caching. to preclude caching.
2.3.2. Calculating Age 2.3.2. Calculating Age
HTTP/1.1 uses the Age response-header field to convey the estimated HTTP/1.1 uses the Age header field to convey the estimated age of the
age of the response message when obtained from a cache. The Age response message when obtained from a cache. The Age field value is
field value is the cache's estimate of the amount of time since the the cache's estimate of the amount of time since the response was
response was generated or validated by the origin server. In generated or validated by the origin server. In essence, the Age
essence, the Age value is the sum of the time that the response has value is the sum of the time that the response has been resident in
been resident in each of the caches along the path from the origin each of the caches along the path from the origin server, plus the
server, plus the amount of time it has been in transit along network amount of time it has been in transit along network paths.
paths.
The following data is used for the age calculation: The following data is used for the age calculation:
age_value age_value
The term "age_value" denotes the value of the Age header field The term "age_value" denotes the value of the Age header field
(Section 3.1), in a form appropriate for arithmetic operation; or (Section 3.1), in a form appropriate for arithmetic operation; or
0, if not available. 0, if not available.
date_value date_value
skipping to change at page 12, line 40 skipping to change at page 12, line 48
possible, with every response, giving the time at which the possible, with every response, giving the time at which the
response was generated. The term "date_value" denotes the value response was generated. The term "date_value" denotes the value
of the Date header field, in a form appropriate for arithmetic of the Date header field, in a form appropriate for arithmetic
operations. See Section 9.3 of [Part1] for the definition of the operations. See Section 9.3 of [Part1] for the definition of the
Date header field, and for requirements regarding responses Date header field, and for requirements regarding responses
without it. without it.
now now
The term "now" means "the current value of the clock at the host The term "now" means "the current value of the clock at the host
performing the calculation". Hosts that use HTTP, but especially performing the calculation". A cache SHOULD use NTP ([RFC1305])
hosts running origin servers and caches, SHOULD use NTP or some similar protocol to synchronize its clocks to a globally
([RFC1305]) or some similar protocol to synchronize their clocks accurate time standard.
to a globally accurate time standard.
request_time request_time
The current value of the clock at the host at the time the request The current value of the clock at the host at the time the request
resulting in the stored response was made. resulting in the stored response was made.
response_time response_time
The current value of the clock at the host at the time the The current value of the clock at the host at the time the
response was received. response was received.
A response's age can be calculated in two entirely independent ways: A response's age can be calculated in two entirely independent ways:
1. the "apparent_age": response_time minus date_value, if the local 1. the "apparent_age": response_time minus date_value, if the local
clock is reasonably well synchronized to the origin server's clock is reasonably well synchronized to the origin server's
clock. If the result is negative, the result is replaced by clock. If the result is negative, the result is replaced by
zero. zero.
2. the "corrected_age_value", if all of the caches along the 2. the "corrected_age_value", if all of the caches along the
response path implement HTTP/1.1; note this value MUST be response path implement HTTP/1.1. A cache MUST interpret this
interpreted relative to the time the request was initiated, not value relative to the time the request was initiated, not the
the time that the response was received. time that the response was received.
apparent_age = max(0, response_time - date_value); apparent_age = max(0, response_time - date_value);
response_delay = response_time - request_time; response_delay = response_time - request_time;
corrected_age_value = age_value + response_delay; corrected_age_value = age_value + response_delay;
These are combined as These are combined as
corrected_initial_age = max(apparent_age, corrected_age_value); corrected_initial_age = max(apparent_age, corrected_age_value);
skipping to change at page 13, line 44 skipping to change at page 13, line 49
resident_time = now - response_time; resident_time = now - response_time;
current_age = corrected_initial_age + resident_time; current_age = corrected_initial_age + resident_time;
2.3.3. Serving Stale Responses 2.3.3. Serving Stale Responses
A "stale" response is one that either has explicit expiry information A "stale" response is one that either has explicit expiry information
or is allowed to have heuristic expiry calculated, but is not fresh or is allowed to have heuristic expiry calculated, but is not fresh
according to the calculations in Section 2.3. according to the calculations in Section 2.3.
Caches MUST NOT return a stale response if it is prohibited by an A cache MUST NOT return a stale response if it is prohibited by an
explicit in-protocol directive (e.g., by a "no-store" or "no-cache" explicit in-protocol directive (e.g., by a "no-store" or "no-cache"
cache directive, a "must-revalidate" cache-response-directive, or an cache directive, a "must-revalidate" cache-response-directive, or an
applicable "s-maxage" or "proxy-revalidate" cache-response-directive; applicable "s-maxage" or "proxy-revalidate" cache-response-directive;
see Section 3.2.2). see Section 3.2.2).
Caches SHOULD NOT return stale responses unless they are disconnected A cache SHOULD NOT return stale responses unless it is disconnected
(i.e., it cannot contact the origin server or otherwise find a (i.e., it cannot contact the origin server or otherwise find a
forward path) or otherwise explicitly allowed (e.g., the max-stale forward path) or otherwise explicitly allowed (e.g., the max-stale
request directive; see Section 3.2.1). request directive; see Section 3.2.1).
Stale responses SHOULD have a Warning header field with the 110 warn- A cache SHOULD append a Warning header field with the 110 warn-code
code (see Section 3.6). Likewise, the 112 warn-code SHOULD be sent (see Section 3.6) to stale responses. Likewise, a cache SHOULD add
on stale responses if the cache is disconnected. the 112 warn-code to stale responses if the cache is disconnected.
If a cache receives a first-hand response (either an entire response, If a cache receives a first-hand response (either an entire response,
or a 304 (Not Modified) response) that it would normally forward to or a 304 (Not Modified) response) that it would normally forward to
the requesting client, and the received response is no longer fresh, the requesting client, and the received response is no longer fresh,
the cache SHOULD forward it to the requesting client without adding a the cache SHOULD forward it to the requesting client without adding a
new Warning (but without removing any existing Warning header new Warning (but without removing any existing Warning header
fields). A cache SHOULD NOT attempt to validate a response simply fields). A cache SHOULD NOT attempt to validate a response simply
because that response became stale in transit. because that response became stale in transit.
2.4. Validation Model 2.4. Validation Model
When a cache has one or more stored responses for a requested URI, When a cache has one or more stored responses for a requested URI,
but cannot serve any of them (e.g., because they are not fresh, or but cannot serve any of them (e.g., because they are not fresh, or
one cannot be selected; see Section 2.7), it can use the conditional one cannot be selected; see Section 2.7), it can use the conditional
request mechanism [Part4] in the forwarded request to give the origin request mechanism [Part4] in the forwarded request to give the origin
server an opportunity to both select a valid stored response to be server an opportunity to both select a valid stored response to be
used, and to update it. This process is known as "validating" or used, and to update it. This process is known as "validating" or
"revalidating" the stored response. "revalidating" the stored response.
When sending such a conditional request, the cache SHOULD add an If- When sending such a conditional request, a cache SHOULD add an If-
Modified-Since header field whose value is that of the Last-Modified Modified-Since header field whose value is that of the Last-Modified
header field from the selected (see Section 2.7) stored response, if header field from the selected (see Section 2.7) stored response, if
available. available.
Additionally, the cache SHOULD add an If-None-Match header field Additionally, a cache SHOULD add an If-None-Match header field whose
whose value is that of the ETag header field(s) from all responses value is that of the ETag header field(s) from all responses stored
stored for the requested URI, if present. However, if any of the for the requested URI, if present. However, if any of the stored
stored responses contains only partial content, its entity-tag SHOULD responses contains only partial content, the cache SHOULD NOT include
NOT be included in the If-None-Match header field unless the request its entity-tag in the If-None-Match header field unless the request
is for a range that would be fully satisfied by that stored response. is for a range that would be fully satisfied by that stored response.
A 304 (Not Modified) response status code indicates that the stored A 304 (Not Modified) response status code indicates that the stored
response can be updated and reused; see Section 2.8. response can be updated and reused; see Section 2.8.
A full response (i.e., one with a response body) indicates that none A full response (i.e., one with a response body) indicates that none
of the stored responses nominated in the conditional request is of the stored responses nominated in the conditional request is
suitable. Instead, the full response SHOULD be used to satisfy the suitable. Instead, a cache SHOULD use the full response to satisfy
request and MAY replace the stored response. the request and MAY replace the stored response.
If a cache receives a 5xx response while attempting to validate a If a cache receives a 5xx response while attempting to validate a
response, it MAY either forward this response to the requesting response, it MAY either forward this response to the requesting
client, or act as if the server failed to respond. In the latter client, or act as if the server failed to respond. In the latter
case, it MAY return a previously stored response (see Section 2.3.3). case, it MAY return a previously stored response (see Section 2.3.3).
2.5. Request Methods that Invalidate 2.5. Request Methods that Invalidate
Because unsafe methods (Section 7.1.1 of [Part2]) have the potential Because unsafe request methods (Section 7.1.1 of [Part2]) have the
for changing state on the origin server, intervening caches can use potential for changing state on the origin server, intervening caches
them to keep their contents up-to-date. can use them to keep their contents up-to-date.
The following HTTP methods MUST cause a cache to invalidate the A cache MUST invalidate the effective Request URI (Section 4.3 of
effective Request URI (Section 4.3 of [Part1]) as well as the URI(s) [Part1]) as well as the URI(s) in the Location and Content-Location
in the Location and Content-Location header fields (if present): header fields (if present) when the following request methods are
received:
o PUT o PUT
o DELETE o DELETE
o POST o POST
An invalidation based on a URI from a Location or Content-Location However, a cache MUST NOT invalidate a URI from a Location or
header field MUST NOT be performed if the host part of that URI Content-Location header field if the host part of that URI differs
differs from the host part in the effective request URI (Section 4.3 from the host part in the effective request URI (Section 4.3 of
of [Part1]). This helps prevent denial of service attacks. [Part1]). This helps prevent denial of service attacks.
A cache that passes through requests for methods it does not A cache that passes through requests with methods it does not
understand SHOULD invalidate the effective request URI (Section 4.3 understand SHOULD invalidate the effective request URI (Section 4.3
of [Part1]). of [Part1]).
Here, "invalidate" means that the cache will either remove all stored Here, "invalidate" means that the cache will either remove all stored
responses related to the effective request URI, or will mark these as responses related to the effective request URI, or will mark these as
"invalid" and in need of a mandatory validation before they can be "invalid" and in need of a mandatory validation before they can be
returned in response to a subsequent request. returned in response to a subsequent request.
Note that this does not guarantee that all appropriate responses are Note that this does not guarantee that all appropriate responses are
invalidated. For example, the request that caused the change at the invalidated. For example, the request that caused the change at the
origin server might not have gone through the cache where a response origin server might not have gone through the cache where a response
is stored. is stored.
2.6. Shared Caching of Authenticated Responses 2.6. Shared Caching of Authenticated Responses
Shared caches MUST NOT use a cached response to a request with an A shared cache MUST NOT use a cached response to a request with an
Authorization header field (Section 4.1 of [Part7]) to satisfy any Authorization header field (Section 4.1 of [Part7]) to satisfy any
subsequent request unless a cache directive that allows such subsequent request unless a cache directive that allows such
responses to be stored is present in the response. responses to be stored is present in the response.
In this specification, the following Cache-Control response In this specification, the following Cache-Control response
directives (Section 3.2.2) have such an effect: must-revalidate, directives (Section 3.2.2) have such an effect: must-revalidate,
public, s-maxage. public, s-maxage.
Note that cached responses that contain the "must-revalidate" and/or Note that cached responses that contain the "must-revalidate" and/or
"s-maxage" response directives are not allowed to be served stale "s-maxage" response directives are not allowed to be served stale
(Section 2.3.3) by shared caches. In particular, a response with (Section 2.3.3) by shared caches. In particular, a response with
either "max-age=0, must-revalidate" or "s-maxage=0" cannot be used to either "max-age=0, must-revalidate" or "s-maxage=0" cannot be used to
satisfy a subsequent request without revalidating it on the origin satisfy a subsequent request without revalidating it on the origin
server. server.
2.7. Caching Negotiated Responses 2.7. Caching Negotiated Responses
When a cache receives a request that can be satisfied by a stored When a cache receives a request that can be satisfied by a stored
response that has a Vary header field (Section 3.5), it MUST NOT use response that has a Vary header field (Section 3.5), it MUST NOT use
that response unless all of the selecting request-header fields that response unless all of the selecting header fields nominated by
nominated by the Vary header field match in both the original request the Vary header field match in both the original request (i.e., that
(i.e., that associated with the stored response), and the presented associated with the stored response), and the presented request.
request.
The selecting request-header fields from two requests are defined to The selecting header fields from two requests are defined to match if
match if and only if those in the first request can be transformed to and only if those in the first request can be transformed to those in
those in the second request by applying any of the following: the second request by applying any of the following:
o adding or removing whitespace, where allowed in the header field's o adding or removing whitespace, where allowed in the header field's
syntax syntax
o combining multiple message-header fields with the same field name o combining multiple header fields with the same field name (see
(see Section 3.2 of [Part1]) Section 3.2 of [Part1])
o normalizing both header field values in a way that is known to o normalizing both header field values in a way that is known to
have identical semantics, according to the header field's have identical semantics, according to the header field's
specification (e.g., re-ordering field values when order is not specification (e.g., re-ordering field values when order is not
significant; case-normalization, where values are defined to be significant; case-normalization, where values are defined to be
case-insensitive) case-insensitive)
If (after any normalization that might take place) a header field is If (after any normalization that might take place) a header field is
absent from a request, it can only match another request if it is absent from a request, it can only match another request if it is
also absent there. also absent there.
A Vary header field-value of "*" always fails to match, and A Vary header field-value of "*" always fails to match, and
subsequent requests to that resource can only be properly interpreted subsequent requests to that resource can only be properly interpreted
by the origin server. by the origin server.
The stored response with matching selecting request-header fields is The stored response with matching selecting header fields is known as
known as the selected response. the selected response.
If no selected response is available, the cache MAY forward the If no selected response is available, the cache MAY forward the
presented request to the origin server in a conditional request; see presented request to the origin server in a conditional request; see
Section 2.4. Section 2.4.
2.8. Combining Responses 2.8. Combining Responses
When a cache receives a 304 (Not Modified) response or a 206 (Partial When a cache receives a 304 (Not Modified) response or a 206 (Partial
Content) response (in this section, the "new" response"), it needs to Content) response (in this section, the "new" response"), it needs to
created an updated response by combining the stored response with the create an updated response by combining the stored response with the
new one, so that the updated response can be used to satisfy the new one, so that the updated response can be used to satisfy the
request, and potentially update the cached response. request, and potentially update the cached response.
If the new response contains an ETag, it identifies the stored If the new response contains an ETag, it identifies the stored
response to use. [[TODO-mention-CL: might need language about response to use. [[TODO-mention-CL: might need language about
Content-Location here]][[TODO-select-for-combine: Shouldn't this be Content-Location here]][[TODO-select-for-combine: Shouldn't this be
the selected response?]] the selected response?]]
If the new response's status code is 206 (partial content), both the When the new response's status code is 206 (partial content), a cache
stored and new responses MUST have validators, and those validators MUST NOT combine it with the old response if either response does not
MUST match using the strong comparison function (see Section 4 of have a validator, and MUST NOT combine it with the old response when
[Part4]). Otherwise, the responses MUST NOT be combined. those validators do not match with the strong comparison function
(see Section 4 of [Part4]).
The stored response header fields are used as those of the updated The stored response header fields are used as those of the updated
response, except that response, except that
o any stored Warning header fields with warn-code 1xx (see o a cache MUST delete any stored Warning header fields with warn-
Section 3.6) MUST be deleted. code 1xx (see Section 3.6).
o any stored Warning header fields with warn-code 2xx MUST be o a cache MUST retain any stored Warning header fields with warn-
retained. code 2xx.
o any other header fields provided in the new response MUST replace o a cache MUST use other header fields provided in the new response
all instances of the corresponding header fields from the stored to replace all instances of the corresponding header fields from
response. the stored response.
The updated response header fields MUST be used to replace those of A cache MUST use the updated response header fields to replace those
the stored response in cache (unless the stored response is removed of the stored response (unless the stored response is removed). In
from cache). In the case of a 206 response, the combined the case of a 206 response, a cache MAY store the combined
representation MAY be stored. representation.
3. Header Field Definitions 3. Header Field Definitions
This section defines the syntax and semantics of HTTP/1.1 header This section defines the syntax and semantics of HTTP/1.1 header
fields related to caching. fields related to caching.
3.1. Age 3.1. Age
The "Age" response-header field conveys the sender's estimate of the The "Age" header field conveys the sender's estimate of the amount of
amount of time since the response was generated or successfully time since the response was generated or successfully validated at
validated at the origin server. Age values are calculated as the origin server. Age values are calculated as specified in
specified in Section 2.3.2. Section 2.3.2.
Age = "Age" ":" OWS Age-v Age = "Age" ":" OWS Age-v
Age-v = delta-seconds Age-v = delta-seconds
Age field-values are non-negative integers, representing time in Age field-values are non-negative integers, representing time in
seconds. seconds.
delta-seconds = 1*DIGIT delta-seconds = 1*DIGIT
If a cache receives a value larger than the largest positive integer If a cache receives a value larger than the largest positive integer
it can represent, or if any of its age calculations overflows, it it can represent, or if any of its age calculations overflows, it
MUST transmit an Age header field with a field-value of 2147483648 MUST transmit an Age header field with a field-value of 2147483648
(2^31). Caches SHOULD use an arithmetic type of at least 31 bits of (2^31). Recipients parsing the Age header field-value SHOULD use an
range. arithmetic type of at least 31 bits of range.
The presence of an Age header field in a response implies that a The presence of an Age header field in a response implies that a
response is not first-hand. However, the converse is not true, since response is not first-hand. However, the converse is not true, since
HTTP/1.0 caches might not implement the Age header field. HTTP/1.0 caches might not implement the Age header field.
3.2. Cache-Control 3.2. Cache-Control
The "Cache-Control" general-header field is used to specify The "Cache-Control" header field is used to specify directives for
directives for caches along the request/response chain. Such cache caches along the request/response chain. Such cache directives are
directives are unidirectional in that the presence of a directive in unidirectional in that the presence of a directive in a request does
a request does not imply that the same directive is to be given in not imply that the same directive is to be given in the response.
the response.
HTTP/1.1 caches MUST obey the requirements of the Cache-Control A cache MUST obey the requirements of the Cache-Control directives
directives defined in this section. See Section 3.2.3 for defined in this section. See Section 3.2.3 for information about how
information about how Cache-Control directives defined elsewhere are Cache-Control directives defined elsewhere are handled.
handled.
Note: HTTP/1.0 caches might not implement Cache-Control and might Note: HTTP/1.0 caches might not implement Cache-Control and might
only implement Pragma: no-cache (see Section 3.4). only implement Pragma: no-cache (see Section 3.4).
Cache directives MUST be passed through by a proxy or gateway A proxy, whether or not it implements a cache, MUST pass cache
application, regardless of their significance to that application, directives through in forwarded messages, regardless of their
since the directives might be applicable to all recipients along the significance to that application, since the directives might be
request/response chain. It is not possible to target a directive to applicable to all recipients along the request/response chain. It is
a specific cache. not possible to target a directive to a specific cache.
Cache-Control = "Cache-Control" ":" OWS Cache-Control-v Cache-Control = "Cache-Control" ":" OWS Cache-Control-v
Cache-Control-v = 1#cache-directive Cache-Control-v = 1#cache-directive
cache-directive = cache-request-directive cache-directive = cache-request-directive
/ cache-response-directive / cache-response-directive
cache-extension = token [ "=" ( token / quoted-string ) ] cache-extension = token [ "=" ( token / quoted-string ) ]
3.2.1. Request Cache-Control Directives 3.2.1. Request Cache-Control Directives
skipping to change at page 19, line 19 skipping to change at page 19, line 27
/ "no-store" / "no-store"
/ "max-age" "=" delta-seconds / "max-age" "=" delta-seconds
/ "max-stale" [ "=" delta-seconds ] / "max-stale" [ "=" delta-seconds ]
/ "min-fresh" "=" delta-seconds / "min-fresh" "=" delta-seconds
/ "no-transform" / "no-transform"
/ "only-if-cached" / "only-if-cached"
/ cache-extension / cache-extension
no-cache no-cache
The no-cache request directive indicates that a stored response The no-cache request directive indicates that a cache MUST NOT use
MUST NOT be used to satisfy the request without successful a stored response to satisfy the request without successful
validation on the origin server. validation on the origin server.
no-store no-store
The no-store request directive indicates that a cache MUST NOT The no-store request directive indicates that a cache MUST NOT
store any part of either this request or any response to it. This store any part of either this request or any response to it. This
directive applies to both non-shared and shared caches. "MUST NOT directive applies to both private and shared caches. "MUST NOT
store" in this context means that the cache MUST NOT intentionally store" in this context means that the cache MUST NOT intentionally
store the information in non-volatile storage, and MUST make a store the information in non-volatile storage, and MUST make a
best-effort attempt to remove the information from volatile best-effort attempt to remove the information from volatile
storage as promptly as possible after forwarding it. storage as promptly as possible after forwarding it.
This directive is NOT a reliable or sufficient mechanism for This directive is NOT a reliable or sufficient mechanism for
ensuring privacy. In particular, malicious or compromised caches ensuring privacy. In particular, malicious or compromised caches
might not recognize or obey this directive, and communications might not recognize or obey this directive, and communications
networks might be vulnerable to eavesdropping. networks might be vulnerable to eavesdropping.
Note that if a request containing this directive is satisfied from
a cache, the no-store request directive does not apply to the
already stored response.
max-age max-age
The max-age request directive indicates that the client is willing The max-age request directive indicates that the client is willing
to accept a response whose age is no greater than the specified to accept a response whose age is no greater than the specified
time in seconds. Unless the max-stale request directive is also time in seconds. Unless the max-stale request directive is also
present, the client is not willing to accept a stale response. present, the client is not willing to accept a stale response.
max-stale max-stale
The max-stale request directive indicates that the client is The max-stale request directive indicates that the client is
skipping to change at page 20, line 16 skipping to change at page 20, line 32
min-fresh min-fresh
The min-fresh request directive indicates that the client is The min-fresh request directive indicates that the client is
willing to accept a response whose freshness lifetime is no less willing to accept a response whose freshness lifetime is no less
than its current age plus the specified time in seconds. That is, than its current age plus the specified time in seconds. That is,
the client wants a response that will still be fresh for at least the client wants a response that will still be fresh for at least
the specified number of seconds. the specified number of seconds.
no-transform no-transform
The no-transform request directive indicates that an intermediate The no-transform request directive indicates that an intermediary
cache or proxy MUST NOT change the Content-Encoding, Content-Range (whether or not it implements a cache) MUST NOT change the
or Content-Type request header fields, nor the request Content-Encoding, Content-Range or Content-Type request header
representation. fields, nor the request representation.
only-if-cached only-if-cached
The only-if-cached request directive indicates that the client The only-if-cached request directive indicates that the client
only wishes to return a stored response. If it receives this only wishes to return a stored response. If it receives this
directive, a cache SHOULD either respond using a stored response directive, a cache SHOULD either respond using a stored response
that is consistent with the other constraints of the request, or that is consistent with the other constraints of the request, or
respond with a 504 (Gateway Timeout) status code. If a group of respond with a 504 (Gateway Timeout) status code. If a group of
caches is being operated as a unified system with good internal caches is being operated as a unified system with good internal
connectivity, such a request MAY be forwarded within that group of connectivity, a member cache MAY forward such a request within
caches. that group of caches.
3.2.2. Response Cache-Control Directives 3.2.2. Response Cache-Control Directives
cache-response-directive = cache-response-directive =
"public" "public"
/ "private" [ "=" DQUOTE 1#field-name DQUOTE ] / "private" [ "=" DQUOTE 1#field-name DQUOTE ]
/ "no-cache" [ "=" DQUOTE 1#field-name DQUOTE ] / "no-cache" [ "=" DQUOTE 1#field-name DQUOTE ]
/ "no-store" / "no-store"
/ "no-transform" / "no-transform"
/ "must-revalidate" / "must-revalidate"
/ "proxy-revalidate" / "proxy-revalidate"
/ "max-age" "=" delta-seconds / "max-age" "=" delta-seconds
/ "s-maxage" "=" delta-seconds / "s-maxage" "=" delta-seconds
/ cache-extension / cache-extension
public public
The public response directive indicates that the response MAY be The public response directive indicates that a response whose
cached, even if it would normally be non-cacheable or cacheable associated request contains an 'Authentication' header MAY be
only within a non-shared cache. (See also Authorization, Section stored (see Section 2.6).
4.1 of [Part7], for additional details.)
private private
The private response directive indicates that the response message The private response directive indicates that the response message
is intended for a single user and MUST NOT be stored by a shared is intended for a single user and MUST NOT be stored by a shared
cache. A private (non-shared) cache MAY store the response. cache. A private cache MAY store the response.
If the private response directive specifies one or more field- If the private response directive specifies one or more field-
names, this requirement is limited to the field-values associated names, this requirement is limited to the field-values associated
with the listed response header fields. That is, the specified with the listed response header fields. That is, a shared cache
field-names(s) MUST NOT be stored by a shared cache, whereas the MUST NOT store the specified field-names(s), whereas it MAY store
remainder of the response message MAY be. the remainder of the response message.
Note: This usage of the word private only controls where the Note: This usage of the word private only controls where the
response can be stored; it cannot ensure the privacy of the response can be stored; it cannot ensure the privacy of the
message content. Also, private response directives with field- message content. Also, private response directives with field-
names are often handled by implementations as if an unqualified names are often handled by implementations as if an unqualified
private directive was received; i.e., the special handling for the private directive was received; i.e., the special handling for the
qualified form is not widely implemented. qualified form is not widely implemented.
no-cache no-cache
The no-cache response directive indicates that the response MUST The no-cache response directive indicates that the response MUST
NOT be used to satisfy a subsequent request without successful NOT be used to satisfy a subsequent request without successful
validation on the origin server. This allows an origin server to validation on the origin server. This allows an origin server to
prevent a cache from using it to satisfy a request without prevent a cache from using it to satisfy a request without
contacting it, even by caches that have been configured to return contacting it, even by caches that have been configured to return
stale responses. stale responses.
If the no-cache response directive specifies one or more field- If the no-cache response directive specifies one or more field-
names, this requirement is limited to the field-values associated names, this requirement is limited to the field-values associated
with the listed response header fields. That is, the specified with the listed response header fields. That is, a cache MUST NOT
field-name(s) MUST NOT be sent in the response to a subsequent send the specified field-name(s) in the response to a subsequent
request without successful validation on the origin server. This request without successful validation on the origin server. This
allows an origin server to prevent the re-use of certain header allows an origin server to prevent the re-use of certain header
fields in a response, while still allowing caching of the rest of fields in a response, while still allowing caching of the rest of
the response. the response.
Note: Most HTTP/1.0 caches will not recognize or obey this Note: Most HTTP/1.0 caches will not recognize or obey this
directive. Also, no-cache response directives with field-names directive. Also, no-cache response directives with field-names
are often handled by implementations as if an unqualified no-cache are often handled by implementations as if an unqualified no-cache
directive was received; i.e., the special handling for the directive was received; i.e., the special handling for the
qualified form is not widely implemented. qualified form is not widely implemented.
no-store no-store
The no-store response directive indicates that a cache MUST NOT The no-store response directive indicates that a cache MUST NOT
store any part of either the immediate request or response. This store any part of either the immediate request or response. This
directive applies to both non-shared and shared caches. "MUST NOT directive applies to both private and shared caches. "MUST NOT
store" in this context means that the cache MUST NOT intentionally store" in this context means that the cache MUST NOT intentionally
store the information in non-volatile storage, and MUST make a store the information in non-volatile storage, and MUST make a
best-effort attempt to remove the information from volatile best-effort attempt to remove the information from volatile
storage as promptly as possible after forwarding it. storage as promptly as possible after forwarding it.
This directive is NOT a reliable or sufficient mechanism for This directive is NOT a reliable or sufficient mechanism for
ensuring privacy. In particular, malicious or compromised caches ensuring privacy. In particular, malicious or compromised caches
might not recognize or obey this directive, and communications might not recognize or obey this directive, and communications
networks might be vulnerable to eavesdropping. networks might be vulnerable to eavesdropping.
must-revalidate must-revalidate
The must-revalidate response directive indicates that once it has The must-revalidate response directive indicates that once it has
become stale, the response MUST NOT be used to satisfy subsequent become stale, a cache MUST NOT use the response to satisfy
requests without successful validation on the origin server. subsequent requests without successful validation on the origin
server.
The must-revalidate directive is necessary to support reliable The must-revalidate directive is necessary to support reliable
operation for certain protocol features. In all circumstances an operation for certain protocol features. In all circumstances a
HTTP/1.1 cache MUST obey the must-revalidate directive; in cache MUST obey the must-revalidate directive; in particular, if a
particular, if the cache cannot reach the origin server for any cache cannot reach the origin server for any reason, it MUST
reason, it MUST generate a 504 (Gateway Timeout) response. generate a 504 (Gateway Timeout) response.
Servers SHOULD send the must-revalidate directive if and only if A server SHOULD send the must-revalidate directive if and only if
failure to validate a request on the representation could result failure to validate a request on the representation could result
in incorrect operation, such as a silently unexecuted financial in incorrect operation, such as a silently unexecuted financial
transaction. transaction.
proxy-revalidate proxy-revalidate
The proxy-revalidate response directive has the same meaning as The proxy-revalidate response directive has the same meaning as
the must-revalidate response directive, except that it does not the must-revalidate response directive, except that it does not
apply to non-shared caches. apply to private caches.
max-age max-age
The max-age response directive indicates that response is to be The max-age response directive indicates that response is to be
considered stale after its age is greater than the specified considered stale after its age is greater than the specified
number of seconds. number of seconds.
s-maxage s-maxage
The s-maxage response directive indicates that, in shared caches, The s-maxage response directive indicates that, in shared caches,
the maximum age specified by this directive overrides the maximum the maximum age specified by this directive overrides the maximum
age specified by either the max-age directive or the Expires age specified by either the max-age directive or the Expires
header field. The s-maxage directive also implies the semantics header field. The s-maxage directive also implies the semantics
of the proxy-revalidate response directive. of the proxy-revalidate response directive.
no-transform no-transform
The no-transform response directive indicates that an intermediate The no-transform response directive indicates that an intermediary
cache or proxy MUST NOT change the Content-Encoding, Content-Range (regardless of whether it implements a cache) MUST NOT change the
or Content-Type response header fields, nor the response Content-Encoding, Content-Range or Content-Type response header
representation. fields, nor the response representation.
3.2.3. Cache Control Extensions 3.2.3. Cache Control Extensions
The Cache-Control header field can be extended through the use of one The Cache-Control header field can be extended through the use of one
or more cache-extension tokens, each with an optional value. or more cache-extension tokens, each with an optional value.
Informational extensions (those that do not require a change in cache Informational extensions (those that do not require a change in cache
behavior) can be added without changing the semantics of other behavior) can be added without changing the semantics of other
directives. Behavioral extensions are designed to work by acting as directives. Behavioral extensions are designed to work by acting as
modifiers to the existing base of cache directives. Both the new modifiers to the existing base of cache directives. Both the new
directive and the standard directive are supplied, such that directive and the standard directive are supplied, such that
skipping to change at page 23, line 35 skipping to change at page 24, line 7
extensions to the cache-control directives can be made without extensions to the cache-control directives can be made without
requiring changes to the base protocol. requiring changes to the base protocol.
This extension mechanism depends on an HTTP cache obeying all of the This extension mechanism depends on an HTTP cache obeying all of the
cache-control directives defined for its native HTTP-version, obeying cache-control directives defined for its native HTTP-version, obeying
certain extensions, and ignoring all directives that it does not certain extensions, and ignoring all directives that it does not
understand. understand.
For example, consider a hypothetical new response directive called For example, consider a hypothetical new response directive called
"community" that acts as a modifier to the private directive. We "community" that acts as a modifier to the private directive. We
define this new directive to mean that, in addition to any non-shared define this new directive to mean that, in addition to any private
cache, any cache that is shared only by members of the community cache, any cache that is shared only by members of the community
named within its value may cache the response. An origin server named within its value may cache the response. An origin server
wishing to allow the UCI community to use an otherwise private wishing to allow the UCI community to use an otherwise private
response in their shared cache(s) could do so by including response in their shared cache(s) could do so by including
Cache-Control: private, community="UCI" Cache-Control: private, community="UCI"
A cache seeing this header field will act correctly even if the cache A cache seeing this header field will act correctly even if the cache
does not understand the community cache-extension, since it will also does not understand the community cache-extension, since it will also
see and understand the private directive and thus default to the safe see and understand the private directive and thus default to the safe
behavior. behavior.
Unrecognized cache directives MUST be ignored; it is assumed that any A cache MUST be ignore unrecognized cache directives; it is assumed
cache directive likely to be unrecognized by an HTTP/1.1 cache will that any cache directive likely to be unrecognized by an HTTP/1.1
be combined with standard directives (or the response's default cache will be combined with standard directives (or the response's
cacheability) such that the cache behavior will remain minimally default cacheability) such that the cache behavior will remain
correct even if the cache does not understand the extension(s). minimally correct even if the cache does not understand the
extension(s).
The HTTP Cache Directive Registry defines the name space for the The HTTP Cache Directive Registry defines the name space for the
cache directives. cache directives.
Registrations MUST include the following fields: A registration MUST include the following fields:
o Cache Directive Name o Cache Directive Name
o Pointer to specification text o Pointer to specification text
Values to be added to this name space are subject to IETF review Values to be added to this name space are subject to IETF review
([RFC5226], Section 4.1). ([RFC5226], Section 4.1).
The registry itself is maintained at The registry itself is maintained at
<http://www.iana.org/assignments/http-cache-directives>. <http://www.iana.org/assignments/http-cache-directives>.
skipping to change at page 24, line 31 skipping to change at page 25, line 4
The "Expires" header field gives the date/time after which the The "Expires" header field gives the date/time after which the
response is considered stale. See Section 2.3 for further discussion response is considered stale. See Section 2.3 for further discussion
of the freshness model. of the freshness model.
The presence of an Expires field does not imply that the original The presence of an Expires field does not imply that the original
resource will change or cease to exist at, before, or after that resource will change or cease to exist at, before, or after that
time. time.
The field-value is an absolute date and time as defined by HTTP-date The field-value is an absolute date and time as defined by HTTP-date
in Section 6.1 of [Part1]; it MUST be sent in rfc1123-date format. in Section 6.1 of [Part1]; a sender MUST use the rfc1123-date format.
Expires = "Expires" ":" OWS Expires-v Expires = "Expires" ":" OWS Expires-v
Expires-v = HTTP-date Expires-v = HTTP-date
For example For example
Expires: Thu, 01 Dec 1994 16:00:00 GMT Expires: Thu, 01 Dec 1994 16:00:00 GMT
Note: If a response includes a Cache-Control field with the max- Note: If a response includes a Cache-Control field with the max-
age directive (see Section 3.2.2), that directive overrides the age directive (see Section 3.2.2), that directive overrides the
Expires field. Likewise, the s-maxage directive overrides Expires Expires field. Likewise, the s-maxage directive overrides Expires
in shared caches. in shared caches.
HTTP/1.1 servers SHOULD NOT send Expires dates more than one year in A server SHOULD NOT send Expires dates more than one year in the
the future. future.
HTTP/1.1 clients and caches MUST treat other invalid date formats, A cache MUST treat other invalid date formats, especially including
especially including the value "0", as in the past (i.e., "already the value "0", as in the past (i.e., "already expired").
expired").
3.4. Pragma 3.4. Pragma
The "Pragma" general-header field is used to include implementation- The "Pragma" header field is used to include implementation-specific
specific directives that might apply to any recipient along the directives that might apply to any recipient along the request/
request/response chain. All pragma directives specify optional response chain. All pragma directives specify optional behavior from
behavior from the viewpoint of the protocol; however, some systems the viewpoint of the protocol; however, some systems MAY require that
MAY require that behavior be consistent with the directives. behavior be consistent with the directives.
Pragma = "Pragma" ":" OWS Pragma-v Pragma = "Pragma" ":" OWS Pragma-v
Pragma-v = 1#pragma-directive Pragma-v = 1#pragma-directive
pragma-directive = "no-cache" / extension-pragma pragma-directive = "no-cache" / extension-pragma
extension-pragma = token [ "=" ( token / quoted-string ) ] extension-pragma = token [ "=" ( token / quoted-string ) ]
When the no-cache directive is present in a request message, an When the no-cache directive is present in a request message, a cache
application SHOULD forward the request toward the origin server even SHOULD forward the request toward the origin server even if it has a
if it has a cached copy of what is being requested. This pragma stored copy of what is being requested. This pragma directive has
directive has the same semantics as the no-cache response directive the same semantics as the no-cache response directive (see
(see Section 3.2.2) and is defined here for backward compatibility Section 3.2.2) and is defined here for backward compatibility with
with HTTP/1.0. Clients SHOULD include both header fields when a no- HTTP/1.0. A client SHOULD include both header fields when a no-cache
cache request is sent to a server not known to be HTTP/1.1 compliant. request is sent to a server not known to be HTTP/1.1 compliant. A
HTTP/1.1 caches SHOULD treat "Pragma: no-cache" as if the client had cache SHOULD treat "Pragma: no-cache" as if the client had sent
sent "Cache-Control: no-cache". "Cache-Control: no-cache".
Note: Because the meaning of "Pragma: no-cache" as a response- Note: Because the meaning of "Pragma: no-cache" as a header field
header field is not actually specified, it does not provide a is not actually specified, it does not provide a reliable
reliable replacement for "Cache-Control: no-cache" in a response. replacement for "Cache-Control: no-cache" in a response.
This mechanism is deprecated; no new Pragma directives will be This mechanism is deprecated; no new Pragma directives will be
defined in HTTP. defined in HTTP.
3.5. Vary 3.5. Vary
The "Vary" response-header field conveys the set of request-header The "Vary" header field conveys the set of header fields that were
fields that were used to select the representation. used to select the representation.
Caches use this information, in part, to determine whether a stored Caches use this information, in part, to determine whether a stored
response can be used to satisfy a given request; see Section 2.7. response can be used to satisfy a given request; see Section 2.7.
determines, while the response is fresh, whether a cache is permitted determines, while the response is fresh, whether a cache is permitted
to use the response to reply to a subsequent request without to use the response to reply to a subsequent request without
validation; see Section 2.7. validation; see Section 2.7.
In uncacheable or stale responses, the Vary field value advises the In uncacheable or stale responses, the Vary field value advises the
user agent about the criteria that were used to select the user agent about the criteria that were used to select the
representation. representation.
Vary = "Vary" ":" OWS Vary-v Vary = "Vary" ":" OWS Vary-v
Vary-v = "*" / 1#field-name Vary-v = "*" / 1#field-name
The set of header fields named by the Vary field value is known as The set of header fields named by the Vary field value is known as
the selecting request-header fields. the selecting header fields.
Servers SHOULD include a Vary header field with any cacheable A server SHOULD include a Vary header field with any cacheable
response that is subject to server-driven negotiation. Doing so response that is subject to server-driven negotiation. Doing so
allows a cache to properly interpret future requests on that resource allows a cache to properly interpret future requests on that resource
and informs the user agent about the presence of negotiation on that and informs the user agent about the presence of negotiation on that
resource. A server MAY include a Vary header field with a non- resource. A server MAY include a Vary header field with a non-
cacheable response that is subject to server-driven negotiation, cacheable response that is subject to server-driven negotiation,
since this might provide the user agent with useful information about since this might provide the user agent with useful information about
the dimensions over which the response varies at the time of the the dimensions over which the response varies at the time of the
response. response.
A Vary field value of "*" signals that unspecified parameters not A Vary field value of "*" signals that unspecified parameters not
limited to the request-header fields (e.g., the network address of limited to the header fields (e.g., the network address of the
the client), play a role in the selection of the response client), play a role in the selection of the response representation;
representation; therefore, a cache cannot determine whether this therefore, a cache cannot determine whether this response is
response is appropriate. The "*" value MUST NOT be generated by a appropriate. A proxy MUST NOT generate the "*" value.
proxy server.
The field-names given are not limited to the set of standard request- The field-names given are not limited to the set of standard header
header fields defined by this specification. Field names are case- fields defined by this specification. Field names are case-
insensitive. insensitive.
3.6. Warning 3.6. Warning
The "Warning" general-header field is used to carry additional The "Warning" header field is used to carry additional information
information about the status or transformation of a message that about the status or transformation of a message that might not be
might not be reflected in the message. This information is typically reflected in the message. This information is typically used to warn
used to warn about possible incorrectness introduced by caching about possible incorrectness introduced by caching operations or
operations or transformations applied to the payload of the message. transformations applied to the payload of the message.
Warnings can be used for other purposes, both cache-related and Warnings can be used for other purposes, both cache-related and
otherwise. The use of a warning, rather than an error status code, otherwise. The use of a warning, rather than an error status code,
distinguishes these responses from true failures. distinguishes these responses from true failures.
Warning header fields can in general be applied to any message, Warning header fields can in general be applied to any message,
however some warn-codes are specific to caches and can only be however some warn-codes are specific to caches and can only be
applied to response messages. applied to response messages.
Warning = "Warning" ":" OWS Warning-v Warning = "Warning" ":" OWS Warning-v
skipping to change at page 27, line 34 skipping to change at page 27, line 44
Systems that generate multiple Warning header fields SHOULD order Systems that generate multiple Warning header fields SHOULD order
them with this user agent behavior in mind. New Warning header them with this user agent behavior in mind. New Warning header
fields SHOULD be added after any existing Warning headers fields. fields SHOULD be added after any existing Warning headers fields.
Warnings are assigned three digit warn-codes. The first digit Warnings are assigned three digit warn-codes. The first digit
indicates whether the Warning is required to be deleted from a stored indicates whether the Warning is required to be deleted from a stored
response after validation: response after validation:
o 1xx Warnings describe the freshness or validation status of the o 1xx Warnings describe the freshness or validation status of the
response, and so MUST be deleted by caches after validation. They response, and so MUST be deleted by a cache after validation.
can only be generated by a cache when validating a cached entry, They can only be generated by a cache when validating a cached
and MUST NOT be generated in any other situation. entry, and MUST NOT be generated in any other situation.
o 2xx Warnings describe some aspect of the representation that is o 2xx Warnings describe some aspect of the representation that is
not rectified by a validation (for example, a lossy compression of not rectified by a validation (for example, a lossy compression of
the representation) and MUST NOT be deleted by caches after the representation) and MUST NOT be deleted by a cache after
validation, unless a full response is returned, in which case they validation, unless a full response is returned, in which case they
MUST be. MUST be.
If an implementation sends a message with one or more Warning header If an implementation sends a message with one or more Warning header
fields to a receiver whose version is HTTP/1.0 or lower, then the fields to a receiver whose version is HTTP/1.0 or lower, then the
sender MUST include in each warning-value a warn-date that matches sender MUST include in each warning-value a warn-date that matches
the Date header field in the message. the Date header field in the message.
If an implementation receives a message with a warning-value that If a system receives a message with a warning-value that includes a
includes a warn-date, and that warn-date is different from the Date warn-date, and that warn-date is different from the Date value in the
value in the response, then that warning-value MUST be deleted from response, then that warning-value MUST be deleted from the message
the message before storing, forwarding, or using it. (preventing the before storing, forwarding, or using it. (preventing the consequences
consequences of naive caching of Warning header fields.) If all of of naive caching of Warning header fields.) If all of the warning-
the warning-values are deleted for this reason, the Warning header values are deleted for this reason, the Warning header field MUST be
field MUST be deleted as well. deleted as well.
The following warn-codes are defined by this specification, each with The following warn-codes are defined by this specification, each with
a recommended warn-text in English, and a description of its meaning. a recommended warn-text in English, and a description of its meaning.
110 Response is stale 110 Response is stale
SHOULD be included whenever the returned response is stale. A cache SHOULD include this whenever the returned response is
stale.
111 Revalidation failed 111 Revalidation failed
SHOULD be included if a cache returns a stale response because an A cache SHOULD include this when returning a stale response
attempt to validate the response failed, due to an inability to because an attempt to validate the response failed, due to an
reach the server. inability to reach the server.
112 Disconnected operation 112 Disconnected operation
SHOULD be included if the cache is intentionally disconnected from A cache SHOULD b include this if it is intentionally disconnected
the rest of the network for a period of time. from the rest of the network for a period of time.
113 Heuristic expiration 113 Heuristic expiration
SHOULD be included if the cache heuristically chose a freshness A cache SHOULD include this if it heuristically chose a freshness
lifetime greater than 24 hours and the response's age is greater lifetime greater than 24 hours and the response's age is greater
than 24 hours. than 24 hours.
199 Miscellaneous warning 199 Miscellaneous warning
The warning text can include arbitrary information to be presented The warning text can include arbitrary information to be presented
to a human user, or logged. A system receiving this warning MUST to a human user, or logged. A system receiving this warning MUST
NOT take any automated action, besides presenting the warning to NOT take any automated action, besides presenting the warning to
the user. the user.
214 Transformation applied 214 Transformation applied
MUST be added by an intermediate proxy if it applies any MUST be added by a proxy if it applies any transformation to the
transformation to the representation, such as changing the representation, such as changing the content-coding, media-type,
content-coding, media-type, or modifying the representation data, or modifying the representation data, unless this Warning code
unless this Warning code already appears in the response. already appears in the response.
299 Miscellaneous persistent warning 299 Miscellaneous persistent warning
The warning text can include arbitrary information to be presented The warning text can include arbitrary information to be presented
to a human user, or logged. A system receiving this warning MUST to a human user, or logged. A system receiving this warning MUST
NOT take any automated action. NOT take any automated action.
4. History Lists 4. History Lists
User agents often have history mechanisms, such as "Back" buttons and User agents often have history mechanisms, such as "Back" buttons and
skipping to change at page 30, line 48 skipping to change at page 31, line 18
suggestions and comments from individuals including: Shel Kaphan, suggestions and comments from individuals including: Shel Kaphan,
Paul Leach, Koen Holtman, David Morris, and Larry Masinter. Paul Leach, Koen Holtman, David Morris, and Larry Masinter.
8. References 8. References
8.1. Normative References 8.1. Normative References
[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
and Message Parsing", draft-ietf-httpbis-p1-messaging-12 and Message Parsing", draft-ietf-httpbis-p1-messaging-13
(work in progress), October 2010. (work in progress), March 2011.
[Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 2: Message and J. Reschke, Ed., "HTTP/1.1, part 2: Message
Semantics", draft-ietf-httpbis-p2-semantics-12 (work in Semantics", draft-ietf-httpbis-p2-semantics-13 (work in
progress), October 2010. progress), March 2011.
[Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional
Requests", draft-ietf-httpbis-p4-conditional-12 (work in Requests", draft-ietf-httpbis-p4-conditional-13 (work in
progress), October 2010. progress), March 2011.
[Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and
Partial Responses", draft-ietf-httpbis-p5-range-12 (work Partial Responses", draft-ietf-httpbis-p5-range-13 (work
in progress), October 2010. in progress), March 2011.
[Part7] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part7] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 7: Authentication", and J. Reschke, Ed., "HTTP/1.1, part 7: Authentication",
draft-ietf-httpbis-p7-auth-12 (work in progress), draft-ietf-httpbis-p7-auth-13 (work in progress),
October 2010. March 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
8.2. Informative References 8.2. Informative References
[RFC1305] Mills, D., "Network Time Protocol (Version 3) [RFC1305] Mills, D., "Network Time Protocol (Version 3)
skipping to change at page 36, line 26 skipping to change at page 36, line 41
C.8. Since draft-ietf-httpbis-p6-cache-06 C.8. Since draft-ietf-httpbis-p6-cache-06
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/161>: "base for o <http://tools.ietf.org/wg/httpbis/trac/ticket/161>: "base for
numeric protocol elements" numeric protocol elements"
Affected issues: Affected issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/37>: WVary and non- o <http://tools.ietf.org/wg/httpbis/trac/ticket/37>: "Vary and non-
existant headers" existant headers"
C.9. Since draft-ietf-httpbis-p6-cache-07 C.9. Since draft-ietf-httpbis-p6-cache-07
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/54>: "Definition of o <http://tools.ietf.org/wg/httpbis/trac/ticket/54>: "Definition of
1xx Warn-Codes" 1xx Warn-Codes"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/167>: "Content- o <http://tools.ietf.org/wg/httpbis/trac/ticket/167>: "Content-
skipping to change at page 38, line 20 skipping to change at page 38, line 33
o Clean up TODOs and prose in "Combining Responses." o Clean up TODOs and prose in "Combining Responses."
C.13. Since draft-ietf-httpbis-p6-cache-11 C.13. Since draft-ietf-httpbis-p6-cache-11
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/204>: "Text about o <http://tools.ietf.org/wg/httpbis/trac/ticket/204>: "Text about
clock requirement for caches belongs in p6" clock requirement for caches belongs in p6"
C.14. Since draft-ietf-httpbis-p6-cache-12
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/224>: "Header
Classification"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/268>: "Clarify
'public'"
Index Index
A A
age 6 age 6
Age header 17 Age header field 18
C C
cache 5 cache 5
Cache Directives Cache Directives
max-age 19, 22 max-age 20, 23
max-stale 19 max-stale 20
min-fresh 20 min-fresh 20
must-revalidate 22 must-revalidate 22
no-cache 19, 21 no-cache 19, 21
no-store 19, 21 no-store 19, 22
no-transform 20, 23 no-transform 20, 23
only-if-cached 20 only-if-cached 20
private 21 private 21
proxy-revalidate 22 proxy-revalidate 23
public 20 public 21
s-maxage 22 s-maxage 23
Cache-Control header 18 Cache-Control header field 18
cacheable 5 cacheable 5
E E
Expires header 24 Expires header field 24
explicit expiration time 5 explicit expiration time 6
F F
first-hand 6 first-hand 6
fresh 6 fresh 6
freshness lifetime 6 freshness lifetime 6
G G
Grammar Grammar
Age 18 Age 18
Age-v 18 Age-v 18
Cache-Control 18 Cache-Control 19
Cache-Control-v 18 Cache-Control-v 19
cache-extension 18 cache-extension 19
cache-request-directive 19 cache-request-directive 19
cache-response-directive 20 cache-response-directive 21
delta-seconds 18 delta-seconds 18
Expires 24 Expires 25
Expires-v 24 Expires-v 25
extension-pragma 25 extension-pragma 25
Pragma 25 Pragma 25
pragma-directive 25 pragma-directive 25
Pragma-v 25 Pragma-v 25
Vary 25 Vary 26
Vary-v 25 Vary-v 26
warn-agent 27 warn-agent 27
warn-code 27 warn-code 27
warn-date 27 warn-date 27
warn-text 27 warn-text 27
Warning 27 Warning 27
Warning-v 27 Warning-v 27
warning-value 27 warning-value 27
H H
Headers Header Fields
Age 17 Age 18
Cache-Control 18 Cache-Control 18
Expires 24 Expires 24
Pragma 25 Pragma 25
Vary 25 Vary 26
Warning 26 Warning 26
heuristic expiration time 5 heuristic expiration time 6
M M
max-age max-age
Cache Directive 19, 22 Cache Directive 20, 23
max-stale max-stale
Cache Directive 19 Cache Directive 20
min-fresh min-fresh
Cache Directive 20 Cache Directive 20
must-revalidate must-revalidate
Cache Directive 22 Cache Directive 22
N N
no-cache no-cache
Cache Directive 19, 21 Cache Directive 19, 21
no-store no-store
Cache Directive 19, 21 Cache Directive 19, 22
no-transform no-transform
Cache Directive 20, 23 Cache Directive 20, 23
O O
only-if-cached only-if-cached
Cache Directive 20 Cache Directive 20
P P
Pragma header 25 Pragma header field 25
private private
Cache Directive 21 Cache Directive 21
private cache 5
proxy-revalidate proxy-revalidate
Cache Directive 22 Cache Directive 23
public public
Cache Directive 20 Cache Directive 21
S S
s-maxage s-maxage
Cache Directive 22 Cache Directive 23
shared cache 5
stale 6 stale 6
V V
validator 6 validator 6
Vary header 25 Vary header field 26
W W
Warning header 26 Warning header field 26
Authors' Addresses Authors' Addresses
Roy T. Fielding (editor) Roy T. Fielding (editor)
Day Software Adobe Systems Incorporated
23 Corporate Plaza DR, Suite 280 345 Park Ave
Newport Beach, CA 92660 San Jose, CA 95110
USA USA
Phone: +1-949-706-5300
Fax: +1-949-706-5305
EMail: fielding@gbiv.com EMail: fielding@gbiv.com
URI: http://roy.gbiv.com/ URI: http://roy.gbiv.com/
Jim Gettys Jim Gettys
Alcatel-Lucent Bell Labs Alcatel-Lucent Bell Labs
21 Oak Knoll Road 21 Oak Knoll Road
Carlisle, MA 01741 Carlisle, MA 01741
USA USA
EMail: jg@freedesktop.org EMail: jg@freedesktop.org
URI: http://gettys.wordpress.com/ URI: http://gettys.wordpress.com/
Jeffrey C. Mogul Jeffrey C. Mogul
skipping to change at page 41, line 29 skipping to change at page 42, line 4
EMail: JeffMogul@acm.org EMail: JeffMogul@acm.org
Henrik Frystyk Nielsen Henrik Frystyk Nielsen
Microsoft Corporation Microsoft Corporation
1 Microsoft Way 1 Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
USA USA
EMail: henrikn@microsoft.com EMail: henrikn@microsoft.com
Larry Masinter Larry Masinter
Adobe Systems, Incorporated Adobe Systems Incorporated
345 Park Ave 345 Park Ave
San Jose, CA 95110 San Jose, CA 95110
USA USA
EMail: LMM@acm.org EMail: LMM@acm.org
URI: http://larry.masinter.net/ URI: http://larry.masinter.net/
Paul J. Leach Paul J. Leach
Microsoft Corporation Microsoft Corporation
1 Microsoft Way 1 Microsoft Way
 End of changes. 137 change blocks. 
296 lines changed or deleted 318 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/