draft-ietf-httpbis-p6-cache-14.txt   draft-ietf-httpbis-p6-cache-15.txt 
HTTPbis Working Group R. Fielding, Ed. HTTPbis Working Group R. Fielding, Ed.
Internet-Draft Adobe 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: October 20, 2011 J. Mogul Expires: January 12, 2012 J. Mogul
HP HP
H. Frystyk H. Frystyk
Microsoft Microsoft
L. Masinter L. Masinter
Adobe 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
April 18, 2011 July 11, 2011
HTTP/1.1, part 6: Caching HTTP/1.1, part 6: Caching
draft-ietf-httpbis-p6-cache-14 draft-ietf-httpbis-p6-cache-15
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.
skipping to change at page 1, line 49 skipping to change at page 1, line 49
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), which is archived at group mailing list (ietf-http-wg@w3.org), which is archived at
<http://lists.w3.org/Archives/Public/ietf-http-wg/>. <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
The current issues list is at The current issues list is at
<http://tools.ietf.org/wg/httpbis/trac/report/3> and related <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.15. The changes in this draft are summarized in Appendix C.16.
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 October 20, 2011. This Internet-Draft will expire on January 12, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
skipping to change at page 3, line 10 skipping to change at page 3, line 10
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 . . . . . . . . . . . . . . . . . . . . . . . 7 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
1.5. Delta Seconds . . . . . . . . . . . . . . . . . . . . . . 8
2. Cache Operation . . . . . . . . . . . . . . . . . . . . . . . 8 2. Cache Operation . . . . . . . . . . . . . . . . . . . . . . . 8
2.1. Response Cacheability . . . . . . . . . . . . . . . . . . 8 2.1. Response Cacheability . . . . . . . . . . . . . . . . . . 8
2.1.1. Storing Partial and Incomplete Responses . . . . . . . 9 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 . . . . . . . . . . . . . . . 14
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 . . . . . . . . 16
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 . . . . . . . . . . . . . . . . . . . 18
3.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 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 . . . . . . . . . . 21 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.6. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.6. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 27
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 . . . . . . . . . . . . . . . . . . . . . . . 31 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
8.1. Normative References . . . . . . . . . . . . . . . . . . . 31 8.1. Normative References . . . . . . . . . . . . . . . . . . . 31
8.2. Informative References . . . . . . . . . . . . . . . . . . 32 8.2. Informative References . . . . . . . . . . . . . . . . . . 32
Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 32 Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 32
skipping to change at page 4, line 13 skipping to change at page 4, line 14
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 . . . . . . . . . . . 36 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 . . . . . . . . . . . 37 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 . . . . . . . . . . . 38 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 C.14. Since draft-ietf-httpbis-p6-cache-12 . . . . . . . . . . . 38
C.15. Since draft-ietf-httpbis-p6-cache-13 . . . . . . . . . . . 38 C.15. Since draft-ietf-httpbis-p6-cache-13 . . . . . . . . . . . 38
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 C.16. Since draft-ietf-httpbis-p6-cache-14 . . . . . . . . . . . 38
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
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 7, line 48 skipping to change at page 7, line 48
quoted-string = <quoted-string, defined in [Part1], Section 1.2.2> quoted-string = <quoted-string, defined in [Part1], Section 1.2.2>
token = <token, defined in [Part1], Section 1.2.2> token = <token, defined in [Part1], Section 1.2.2>
OWS = <OWS, defined in [Part1], Section 1.2.2> OWS = <OWS, defined in [Part1], Section 1.2.2>
1.4.2. ABNF Rules defined in other Parts of the Specification 1.4.2. ABNF Rules defined in other Parts of the Specification
The ABNF rules below are defined in other parts: The ABNF rules below are defined in other parts:
field-name = <field-name, defined in [Part1], Section 3.2> field-name = <field-name, defined in [Part1], Section 3.2>
HTTP-date = <HTTP-date, defined in [Part1], Section 6.1> HTTP-date = <HTTP-date, defined in [Part1], Section 6.1>
port = <port, defined in [Part1], Section 2.6> port = <port, defined in [Part1], Section 2.7>
pseudonym = <pseudonym, defined in [Part1], Section 9.9> pseudonym = <pseudonym, defined in [Part1], Section 9.9>
uri-host = <uri-host, defined in [Part1], Section 2.6> uri-host = <uri-host, defined in [Part1], Section 2.7>
1.5. Delta Seconds
The delta-seconds rule specifies a non-negative integer, representing
time in seconds.
delta-seconds = 1*DIGIT
If an implementation receives a delta-seconds value larger than the
largest positive integer it can represent, or if any of its
subsequent calculations overflows, it MUST consider the value to be
2147483648 (2^31). Recipients parsing a delta-seconds value SHOULD
use an arithmetic type of at least 31 bits of range, and senders MUST
NOT send delta-seconds with a value greater than 2147483648.
2. Cache Operation 2. Cache Operation
2.1. Response Cacheability 2.1. Response Cacheability
A cache MUST NOT store a response to any request, unless: A cache MUST NOT store a response to any request, unless:
o The request method is understood by the cache and defined as being o The request method is understood by the cache and defined as being
cacheable, and cacheable, and
skipping to change at page 8, line 42 skipping to change at page 9, line 8
* contains a s-maxage response cache directive and the cache is * contains a s-maxage response cache directive and the cache is
shared, or shared, or
* contains a Cache Control Extension (see Section 3.2.3) that * contains a Cache Control Extension (see Section 3.2.3) that
allows it to be cached, or allows it to be cached, or
* has a status code that can be served with heuristic freshness * has a status code that can be served with heuristic freshness
(see Section 2.3.1.1). (see Section 2.3.1.1).
Note that any of the requirements listed above can be overridden by a
cache-control extension; see Section 3.2.3.
In this context, a cache has "understood" a request method or a In this context, a cache has "understood" a request method or a
response status code if it recognises it and implements any cache- response status code if it recognises it and implements any cache-
specific behaviour. In particular, 206 Partial Content responses specific behavior. In particular, 206 Partial Content responses
cannot be cached by an implementation that does not handle partial cannot be cached by an implementation that does not handle partial
content (see Section 2.1.1). content (see Section 2.1.1).
Note that in normal operation, most caches will not store a response Note that in normal operation, most caches will not store a response
that has neither a cache validator nor an explicit expiration time, that has neither a cache validator nor an explicit expiration time,
as such responses are not usually useful to store. However, caches as such responses are not usually useful to store. However, caches
are not prohibited from storing such responses. are not prohibited from storing such responses.
2.1.1. Storing Partial and Incomplete Responses 2.1.1. Storing Partial and Incomplete Responses
skipping to change at page 9, line 44 skipping to change at page 10, line 13
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).
Note that any of the requirements listed above can be overridden by a
cache-control extension; see Section 3.2.3.
When a stored response is used to satisfy a request without When a stored response is used to satisfy a request without
validation, a cache 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.
A cache MUST write through requests with methods that are unsafe A cache MUST write through requests with methods that are unsafe
(Section 7.1.1 of [Part2]) 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 generate a reply to such a request before having forwarded the not generate a reply to such a request before having forwarded the
request and 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.
A cache MUST use the most recent response (as determined by the Date When more than one suitable response is stored, a cache MUST use the
header field) when more than one suitable response is stored. It can most recent response (as determined by the Date header field). It
also forward a request with "Cache-Control: max-age=0" or "Cache- can 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.
A cache that does not have a clock available MUST NOT use stored A cache that does not have a clock available MUST NOT use stored
responses without revalidating them on every use. A cache, responses without revalidating them on every use. A cache,
especially a shared cache, SHOULD use a mechanism, such as NTP especially a shared cache, SHOULD use a mechanism, such as NTP
[RFC1305], to synchronize its clock with a reliable external [RFC1305], to synchronize its clock with a reliable external
standard. standard.
2.3. Freshness Model 2.3. Freshness Model
skipping to change at page 11, line 10 skipping to change at page 11, line 30
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
effect of either increasing or loosening constraints on freshness. effect of either increasing or loosening constraints on freshness.
See Section 3.2.1. See Section 3.2.1.
[[ISSUE-no-req-for-directives: there are not requirements directly
applying to cache-request-directives and freshness.]]
Note that freshness applies only to cache operation; it cannot be Note that freshness applies only to cache operation; it cannot be
used to force a user agent to refresh its display or reload a used to force a user agent to refresh its display or reload a
resource. See Section 4 for an explanation of the difference between resource. See Section 4 for an explanation of the difference between
caches and history mechanisms. caches and history mechanisms.
2.3.1. Calculating Freshness Lifetime 2.3.1. Calculating Freshness Lifetime
A cache can calculate the freshness lifetime (denoted as A cache can calculate the freshness lifetime (denoted as
freshness_lifetime) of a response by using the first match of: freshness_lifetime) of a response by using the first match of:
skipping to change at page 15, line 13 skipping to change at page 15, line 33
suitable. Instead, a cache SHOULD use the full response to satisfy suitable. Instead, a cache SHOULD use the full response to satisfy
the 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 request methods (Section 7.1.1 of [Part2]) have the Because unsafe request methods (Section 7.1.1 of [Part2]) such as
potential for changing state on the origin server, intervening caches PUT, POST or DELETE have the potential for changing state on the
can use them to keep their contents up-to-date. origin server, intervening caches can use them to keep their contents
up-to-date.
A cache MUST invalidate the effective Request URI (Section 4.3 of A cache MUST invalidate the effective Request URI (Section 4.3 of
[Part1]) as well as the URI(s) in the Location and Content-Location [Part1]) as well as the URI(s) in the Location and Content-Location
header fields (if present) when the following request methods are header fields (if present) when a non-error response to a request
received: with an unsafe method is received.
o PUT
o DELETE
o POST
However, a cache MUST NOT invalidate a URI from a Location or However, a cache MUST NOT invalidate a URI from a Location or
Content-Location header field if the host part of that URI differs Content-Location header field if the host part of that URI differs
from the host part in the effective request URI (Section 4.3 of from the host part in the effective request URI (Section 4.3 of
[Part1]). This helps prevent denial of service attacks. [Part1]). This helps prevent denial of service attacks.
A cache that passes through requests with methods it does not A cache SHOULD invalidate the effective request URI (Section 4.3 of
understand SHOULD invalidate the effective request URI (Section 4.3 [Part1]) when it receives a non-error response to a request with a
of [Part1]). method whose safety is unknown.
Here, "invalidate" means that the cache will either remove all stored Here, a "non-error response" is one with a 2xx or 3xx status code.
"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
skipping to change at page 17, line 5 skipping to change at page 17, line 22
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 header fields is known as The stored response with matching selecting header fields is known as
the selected response. the selected response.
If multiple selected responses are available, the most recent
response (as determined by the Date header field) is used; see
Section 2.2.
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
create 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
skipping to change at page 18, line 15 skipping to change at page 18, line 34
3.1. Age 3.1. Age
The "Age" header field conveys the sender's estimate of the amount of The "Age" header field conveys the sender's estimate of the amount of
time since the response was generated or successfully validated at time since the response was generated or successfully validated at
the origin server. Age values are calculated as specified in the origin server. Age values are calculated as specified in
Section 2.3.2. Section 2.3.2.
Age = delta-seconds Age = delta-seconds
Age field-values are non-negative integers, representing time in Age field-values are non-negative integers, representing time in
seconds. seconds (see Section 1.5).
delta-seconds = 1*DIGIT
If a cache receives a value larger than the largest positive integer
it can represent, or if any of its age calculations overflows, it
MUST transmit an Age header field with a field-value of 2147483648
(2^31). Recipients parsing the Age header field-value SHOULD use an
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" header field is used to specify directives for The "Cache-Control" header field is used to specify directives for
caches along the request/response chain. Such cache directives are caches along the request/response chain. Such cache directives are
unidirectional in that the presence of a directive in a request does unidirectional in that the presence of a directive in a request does
skipping to change at page 19, line 51 skipping to change at page 20, line 11
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 Note that if a request containing this directive is satisfied from
a cache, the no-store request directive does not apply to the a cache, the no-store request directive does not apply to the
already stored response. 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
to accept a response whose age is no greater than the specified unwilling to accept a response whose age is greater than the
time in seconds. Unless the max-stale request directive is also specified number of seconds. Unless the max-stale request
present, the client is not willing to accept a stale response. directive is also 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
willing to accept a response that has exceeded its expiration willing to accept a response that has exceeded its expiration
time. If max-stale is assigned a value, then the client is time. If max-stale is assigned a value, then the client is
willing to accept a response that has exceeded its expiration time willing to accept a response that has exceeded its expiration time
by no more than the specified number of seconds. If no value is by no more than the specified number of seconds. If no value is
assigned to max-stale, then the client is willing to accept a assigned to max-stale, then the client is willing to accept a
stale response of any age. stale response of any age.
skipping to change at page 20, line 35 skipping to change at page 20, line 45
no-transform no-transform
The no-transform request directive indicates that an intermediary The no-transform request directive indicates that an intermediary
(whether or not it implements a cache) MUST NOT change the (whether or not it implements a cache) MUST NOT change the
Content-Encoding, Content-Range or Content-Type request header Content-Encoding, Content-Range or Content-Type request header
fields, nor the request 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 obtain 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, a member cache MAY forward such a request within connectivity, a member cache MAY forward such a request within
that group of 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 =
skipping to change at page 24, line 20 skipping to change at page 24, line 20
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.
A cache MUST be ignore unrecognized cache directives; it is assumed A cache MUST ignore unrecognized cache directives; it is assumed that
that any cache directive likely to be unrecognized by an HTTP/1.1 any cache directive likely to be unrecognized by an HTTP/1.1 cache
cache will be combined with standard directives (or the response's will be combined with standard directives (or the response's default
default cacheability) such that the cache behavior will remain cacheability) such that the cache behavior will remain minimally
minimally correct even if the cache does not understand the correct even if the cache does not understand the extension(s).
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.
A registration 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
skipping to change at page 25, line 25 skipping to change at page 25, line 24
in shared caches. in shared caches.
A server SHOULD NOT send Expires dates more than one year in the A server SHOULD NOT send Expires dates more than one year in the
future. future.
A cache MUST treat other invalid date formats, especially including A cache MUST treat other invalid date formats, especially including
the value "0", as in the past (i.e., "already expired"). the value "0", as in the past (i.e., "already expired").
3.4. Pragma 3.4. Pragma
The "Pragma" header field is used to include implementation-specific The "Pragma" header field allows backwards compatibility with
directives that might apply to any recipient along the request/ HTTP/1.0 caches, so that clients can specify a "no-cache" request
response chain. All pragma directives specify optional behavior from that they will understand (as Cache-Control was not defined until
the viewpoint of the protocol; however, some systems MAY require that HTTP/1.1). When the Cache-Control header is also present and
behavior be consistent with the directives. understood in a request, Pragma is ignored.
In HTTP/1.0, Pragma was defined as an extensible field for
implementation-specified directives for recipients. This
specification deprecates such extensions to improve interoperability.
Pragma = 1#pragma-directive Pragma = 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, a cache When the Cache-Control header is not present in a request, the no-
SHOULD forward the request toward the origin server even if it has a cache request pragma-directive MUST have the same effect on caches as
stored copy of what is being requested. This pragma directive has if "Cache-Control: no-cache" were present (see Section 3.2.1).
the same semantics as the no-cache response directive (see
Section 3.2.2) and is defined here for backward compatibility with
HTTP/1.0. A client SHOULD include both header fields when a no-cache
request is sent to a server not known to be HTTP/1.1 compliant. A
cache SHOULD treat "Pragma: no-cache" as if the client had sent
"Cache-Control: no-cache".
Note: Because the meaning of "Pragma: no-cache" as a header field When sending a no-cache request, a client SHOULD include both pragma
is not actually specified, it does not provide a reliable and cache-control directives unless Cache-Control: no-cache is
replacement for "Cache-Control: no-cache" in a response. purposefully omitted to target other Cache-Control response
directives at HTTP/1.1 caches. For example:
This mechanism is deprecated; no new Pragma directives will be GET / HTTP/1.1
defined in HTTP. Host: www.example.com
Cache-Control: max-age=30
Pragma: no-cache
will constrain HTTP/1.1 caches to serve a response no older than 30
seconds, while precluding implementations that do not understand
Cache-Control from serving a cached response.
Note: Because the meaning of "Pragma: no-cache" in responses is
not specified, it does not provide a reliable replacement for
"Cache-Control: no-cache" in them.
3.5. Vary 3.5. Vary
The "Vary" header field conveys the set of header fields that were The "Vary" header field conveys the set of header 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
skipping to change at page 31, line 18 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-14 and Message Parsing", draft-ietf-httpbis-p1-messaging-15
(work in progress), April 2011. (work in progress), July 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-14 (work in Semantics", draft-ietf-httpbis-p2-semantics-15 (work in
progress), April 2011. progress), July 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-14 (work in Requests", draft-ietf-httpbis-p4-conditional-15 (work in
progress), April 2011. progress), July 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-14 (work Partial Responses", draft-ietf-httpbis-p5-range-15 (work
in progress), April 2011. in progress), July 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-14 (work in progress), draft-ietf-httpbis-p7-auth-15 (work in progress),
April 2011. July 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 33, line 36 skipping to change at page 33, line 36
field-name ] ) DQUOTE ] ) / "no-store" / "no-transform" / field-name ] ) DQUOTE ] ) / "no-store" / "no-transform" /
"must-revalidate" / "proxy-revalidate" / ( "max-age=" delta-seconds "must-revalidate" / "proxy-revalidate" / ( "max-age=" delta-seconds
) / ( "s-maxage=" delta-seconds ) / cache-extension ) / ( "s-maxage=" delta-seconds ) / cache-extension
delta-seconds = 1*DIGIT delta-seconds = 1*DIGIT
extension-pragma = token [ "=" ( token / quoted-string ) ] extension-pragma = token [ "=" ( token / quoted-string ) ]
field-name = <field-name, defined in [Part1], Section 3.2> field-name = <field-name, defined in [Part1], Section 3.2>
port = <port, defined in [Part1], Section 2.6> port = <port, defined in [Part1], Section 2.7>
pragma-directive = "no-cache" / extension-pragma pragma-directive = "no-cache" / extension-pragma
pseudonym = <pseudonym, defined in [Part1], Section 9.9> pseudonym = <pseudonym, defined in [Part1], Section 9.9>
quoted-string = <quoted-string, defined in [Part1], Section 1.2.2> quoted-string = <quoted-string, defined in [Part1], Section 1.2.2>
token = <token, defined in [Part1], Section 1.2.2> token = <token, defined in [Part1], Section 1.2.2>
uri-host = <uri-host, defined in [Part1], Section 2.6> uri-host = <uri-host, defined in [Part1], Section 2.7>
warn-agent = ( uri-host [ ":" port ] ) / pseudonym warn-agent = ( uri-host [ ":" port ] ) / pseudonym
warn-code = 3DIGIT warn-code = 3DIGIT
warn-date = DQUOTE HTTP-date DQUOTE warn-date = DQUOTE HTTP-date DQUOTE
warn-text = quoted-string warn-text = quoted-string
warning-value = warn-code SP warn-agent SP warn-text [ SP warn-date warning-value = warn-code SP warn-agent SP warn-text [ SP warn-date
] ]
ABNF diagnostics: ABNF diagnostics:
skipping to change at page 37, line 18 skipping to change at page 37, line 18
C.10. Since draft-ietf-httpbis-p6-cache-08 C.10. Since draft-ietf-httpbis-p6-cache-08
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/147>: "serving o <http://tools.ietf.org/wg/httpbis/trac/ticket/147>: "serving
negotiated responses from cache: header-specific canonicalization" negotiated responses from cache: header-specific canonicalization"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/197>: "Effect of CC o <http://tools.ietf.org/wg/httpbis/trac/ticket/197>: "Effect of CC
directives on history lists" directives on history lists"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/291>: "Cache
Extensions can override no-store, etc."
Affected issues: Affected issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/199>: Status codes o <http://tools.ietf.org/wg/httpbis/trac/ticket/199>: Status codes
and caching and caching
Partly resolved issues: Partly resolved issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/60>: "Placement of o <http://tools.ietf.org/wg/httpbis/trac/ticket/60>: "Placement of
13.5.1 and 13.5.2" 13.5.1 and 13.5.2"
skipping to change at page 38, line 18 skipping to change at page 38, line 21
o <http://tools.ietf.org/wg/httpbis/trac/ticket/109>: "Clarify o <http://tools.ietf.org/wg/httpbis/trac/ticket/109>: "Clarify
entity / representation / variant terminology" entity / representation / variant terminology"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider o <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider
removing the 'changes from 2068' sections" removing the 'changes from 2068' sections"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/223>: "Allowing o <http://tools.ietf.org/wg/httpbis/trac/ticket/223>: "Allowing
heuristic caching for new status codes" heuristic caching for new status codes"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/223>: "Allowing
heuristic caching for new status codes"
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 C.14. Since draft-ietf-httpbis-p6-cache-12
skipping to change at page 38, line 47 skipping to change at page 38, line 47
o <http://tools.ietf.org/wg/httpbis/trac/ticket/268>: "Clarify o <http://tools.ietf.org/wg/httpbis/trac/ticket/268>: "Clarify
'public'" 'public'"
C.15. Since draft-ietf-httpbis-p6-cache-13 C.15. Since draft-ietf-httpbis-p6-cache-13
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle
ABNFs for header fields" ABNFs for header fields"
C.16. Since draft-ietf-httpbis-p6-cache-14
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/38>: "Mismatch Vary"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/235>: "Cache
Invalidation only happens upon successful responses"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/282>: "Recommend
minimum sizes for protocol elements"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/289>: "Proxies don't
'understand' methods"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/292>: "Pragma"
Index Index
A A
age 6 age 6
Age header field 18 Age header field 18
C C
cache 5 cache 5
Cache Directives Cache Directives
max-age 19, 23 max-age 20, 23
max-stale 20 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, 22 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 23 proxy-revalidate 23
public 21 public 21
skipping to change at page 39, line 39 skipping to change at page 40, line 7
fresh 6 fresh 6
freshness lifetime 6 freshness lifetime 6
G G
Grammar Grammar
Age 18 Age 18
Cache-Control 19 Cache-Control 19
cache-extension 19 cache-extension 19
cache-request-directive 19 cache-request-directive 19
cache-response-directive 21 cache-response-directive 21
delta-seconds 18 delta-seconds 8
Expires 25 Expires 25
extension-pragma 25 extension-pragma 25
Pragma 25 Pragma 25
pragma-directive 25 pragma-directive 25
Vary 26 Vary 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-value 27 warning-value 27
H H
Header Fields Header Fields
Age 18 Age 18
Cache-Control 18 Cache-Control 18
Expires 24 Expires 24
Pragma 25 Pragma 25
Vary 26 Vary 26
Warning 26 Warning 27
heuristic expiration time 6 heuristic expiration time 6
M M
max-age max-age
Cache Directive 19, 23 Cache Directive 20, 23
max-stale max-stale
Cache Directive 20 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
skipping to change at page 41, line 8 skipping to change at page 41, line 26
s-maxage s-maxage
Cache Directive 23 Cache Directive 23
shared cache 5 shared cache 5
stale 6 stale 6
V V
validator 6 validator 6
Vary header field 26 Vary header field 26
W W
Warning header field 26 Warning header field 27
Authors' Addresses Authors' Addresses
Roy T. Fielding (editor) Roy T. Fielding (editor)
Adobe Systems Incorporated Adobe Systems Incorporated
345 Park Ave 345 Park Ave
San Jose, CA 95110 San Jose, CA 95110
USA USA
EMail: fielding@gbiv.com EMail: fielding@gbiv.com
 End of changes. 46 change blocks. 
93 lines changed or deleted 129 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/