draft-ietf-httpbis-p6-cache-08.txt   draft-ietf-httpbis-p6-cache-latest.txt 
HTTPbis Working Group R. Fielding, Ed. HTTPbis Working Group R. Fielding, Ed.
Internet-Draft Day Software Internet-Draft Day Software
Obsoletes: 2616 (if approved) J. Gettys Obsoletes: 2616 (if approved) J. Gettys
Intended status: Standards Track One Laptop per Child Intended status: Standards Track One Laptop per Child
Expires: April 29, 2010 J. Mogul Expires: August 6, 2010 J. Mogul
HP HP
H. Frystyk H. Frystyk
Microsoft Microsoft
L. Masinter L. Masinter
Adobe Systems Adobe Systems
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 26, 2009 February 2, 2010
HTTP/1.1, part 6: Caching HTTP/1.1, part 6: Caching
draft-ietf-httpbis-p6-cache-08 draft-ietf-httpbis-p6-cache-latest
Status of this Memo Abstract
The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information
systems. This document is Part 6 of the seven-part specification
that defines the protocol referred to as "HTTP/1.1" and, taken
together, obsoletes RFC 2616. Part 6 defines requirements on HTTP
caches and the associated header fields that control cache behavior
or indicate cacheable response messages.
Editorial Note (To be removed by RFC Editor)
Discussion of this draft should take place on the HTTPBIS working
group mailing list (ietf-http-wg@w3.org). The current issues list is
at <http://tools.ietf.org/wg/httpbis/trac/report/11> and related
documents (including fancy diffs) can be found at
<http://tools.ietf.org/wg/httpbis/>.
The changes in this draft are summarized in Appendix C.10.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79.
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 29, 2010. This Internet-Draft will expire on August 6, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
The Hypertext Transfer Protocol (HTTP) is an application-level described in the BSD License.
protocol for distributed, collaborative, hypermedia information
systems. This document is Part 6 of the seven-part specification
that defines the protocol referred to as "HTTP/1.1" and, taken
together, obsoletes RFC 2616. Part 6 defines requirements on HTTP
caches and the associated header fields that control cache behavior
or indicate cacheable response messages.
Editorial Note (To be removed by RFC Editor)
Discussion of this draft should take place on the HTTPBIS working
group mailing list (ietf-http-wg@w3.org). The current issues list is
at <http://tools.ietf.org/wg/httpbis/trac/report/11> and related
documents (including fancy diffs) can be found at
<http://tools.ietf.org/wg/httpbis/>.
The changes in this draft are summarized in Appendix C.9. This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
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 . . . . . . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Response Cacheability . . . . . . . . . . . . . . . . . . 7 2.1. Response Cacheability . . . . . . . . . . . . . . . . . . 7
2.1.1. Storing Partial and Incomplete Responses . . . . . . . 8 2.1.1. Storing Partial and Incomplete Responses . . . . . . . 8
2.2. Constructing Responses from Caches . . . . . . . . . . . . 8 2.2. Constructing Responses from Caches . . . . . . . . . . . . 9
2.3. Freshness Model . . . . . . . . . . . . . . . . . . . . . 9 2.3. Freshness Model . . . . . . . . . . . . . . . . . . . . . 10
2.3.1. Calculating Freshness Lifetime . . . . . . . . . . . . 10 2.3.1. Calculating Freshness Lifetime . . . . . . . . . . . . 11
2.3.2. Calculating Age . . . . . . . . . . . . . . . . . . . 11 2.3.2. Calculating Age . . . . . . . . . . . . . . . . . . . 12
2.3.3. Serving Stale Responses . . . . . . . . . . . . . . . 13 2.3.3. Serving Stale Responses . . . . . . . . . . . . . . . 13
2.4. Validation Model . . . . . . . . . . . . . . . . . . . . . 13 2.4. Validation Model . . . . . . . . . . . . . . . . . . . . . 14
2.5. Request Methods that Invalidate . . . . . . . . . . . . . 14 2.5. Request Methods that Invalidate . . . . . . . . . . . . . 14
2.6. Caching Negotiated Responses . . . . . . . . . . . . . . . 15 2.6. Caching Negotiated Responses . . . . . . . . . . . . . . . 15
2.7. Combining Responses . . . . . . . . . . . . . . . . . . . 16 2.7. Combining Responses . . . . . . . . . . . . . . . . . . . 16
3. Header Field Definitions . . . . . . . . . . . . . . . . . . . 16 3. Header Field Definitions . . . . . . . . . . . . . . . . . . . 17
3.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 17 3.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 17
3.2.1. Request Cache-Control Directives . . . . . . . . . . . 18 3.2.1. Request Cache-Control Directives . . . . . . . . . . . 18
3.2.2. Response Cache-Control Directives . . . . . . . . . . 20 3.2.2. Response Cache-Control Directives . . . . . . . . . . 20
3.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 22 3.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 22
3.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.6. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.6. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 25
4. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 28 4. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 28
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
5.1. Message Header Registration . . . . . . . . . . . . . . . 28 5.1. Message Header Registration . . . . . . . . . . . . . . . 28
6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.1. Normative References . . . . . . . . . . . . . . . . . . . 29 8.1. Normative References . . . . . . . . . . . . . . . . . . . 29
8.2. Informative References . . . . . . . . . . . . . . . . . . 30 8.2. Informative References . . . . . . . . . . . . . . . . . . 30
Appendix A. Compatibility with Previous Versions . . . . . . . . 30 Appendix A. Compatibility with Previous Versions . . . . . . . . 31
A.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 31 A.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 31
A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 31 A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 31
Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 31 Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 31
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) . . . . . . . . . . . . . . . . . . . . 33
C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 33 C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 33
C.2. Since draft-ietf-httpbis-p6-cache-00 . . . . . . . . . . . 33 C.2. Since draft-ietf-httpbis-p6-cache-00 . . . . . . . . . . . 33
C.3. Since draft-ietf-httpbis-p6-cache-01 . . . . . . . . . . . 34 C.3. Since draft-ietf-httpbis-p6-cache-01 . . . . . . . . . . . 34
C.4. Since draft-ietf-httpbis-p6-cache-02 . . . . . . . . . . . 34 C.4. Since draft-ietf-httpbis-p6-cache-02 . . . . . . . . . . . 34
C.5. Since draft-ietf-httpbis-p6-cache-03 . . . . . . . . . . . 34 C.5. Since draft-ietf-httpbis-p6-cache-03 . . . . . . . . . . . 34
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 . . . . . . . . . . . 35
C.8. Since draft-ietf-httpbis-p6-cache-06 . . . . . . . . . . . 35 C.8. Since draft-ietf-httpbis-p6-cache-06 . . . . . . . . . . . 35
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
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 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.
skipping to change at page 8, line 5 skipping to change at page 8, line 5
port = <port, defined in [Part1], Section 2.6> port = <port, defined in [Part1], Section 2.6>
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.6>
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 defined as being cacheable, and o The request method is understood by the cache and defined as being
cacheable, and
o the response status code is understood by the cache, and
o the "no-store" cache directive (see Section 3.2) does not appear o the "no-store" cache directive (see Section 3.2) does not appear
in request or response headers, and in request or response headers, and
o the "private" cache response directive (see Section 3.2 does not o the "private" cache response directive (see Section 3.2.2 does not
appear in the response, if the cache is shared, and appear in the response, if the cache is shared, and
o the "Authorization" header (see Section 3.1 of [Part7]) does not o the "Authorization" header (see Section 3.1 of [Part7]) does not
appear in the request, if the cache is shared (unless the "public" appear in the request, if the cache is shared (unless the "public"
directive is present; see Section 3.2), and directive is present; see Section 3.2), and
o the cache understands partial responses, if the response is o the response either:
partial or incomplete (see Section 2.1.1).
* contains an Expires header (see Section 3.3), or
* contains a max-age response cache directive (see
Section 3.2.2), or
* contains a s-maxage response cache directive and the cache is
shared, or
* contains a Cache Control Extension (see Section 3.2.3) that
allows it to be cached, or
* has a status code that can be served with heuristic freshness
(see Section 2.3.1.1).
In this context, a cache has "understood" a request method or a
response status code if it recognises it and implements any cache-
specific behaviour. In particular, 206 Partial Content responses
cannot be cached by an implementation that does not handle partial
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
A cache that receives an incomplete response (for example, with fewer A cache that receives an incomplete response (for example, with fewer
bytes of data than specified in a Content-Length header) can store bytes of data than specified in a Content-Length header) can store
skipping to change at page 9, line 28 skipping to change at page 9, line 50
[[TODO-method-cacheability: define method cacheability for GET, HEAD [[TODO-method-cacheability: define method cacheability for GET, HEAD
and POST in p2-semantics.]] and POST in p2-semantics.]]
When a stored response is used to satisfy a request, caches MUST When a stored response is used to satisfy a request, caches MUST
include a single Age header field (Section 3.1) in the response with include a single Age header field (Section 3.1) in the response with
a value equal to the stored response's current_age; see a value equal to the stored response's current_age; see
Section 2.3.2. [[anchor1: DISCUSS: this currently includes Section 2.3.2. [[anchor1: DISCUSS: this currently includes
successfully validated responses.]] successfully validated responses.]]
Requests with methods that are unsafe (Section 7.1.1 of [Part2]) MUST Requests with methods that are unsafe (Section 7.1.1 of [Part2]) MUST
be written through the cache to the origin server; i.e., A cache must be written through the cache to the origin server; i.e., a cache must
not reply to such a request before having forwarded the request and not reply to such a request before having forwarded the request and
having received a corresponding response. 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 Caches MUST use the most recent response (as determined by the Date
header) when more than one suitable response is stored. They can header) when more than one suitable response is stored. They 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.
skipping to change at page 20, line 42 skipping to change at page 20, line 42
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 headers. That is, the specified field- with the listed response headers. That is, the specified field-
names(s) MUST NOT be stored by a shared cache, whereas the names(s) MUST NOT be stored by a shared cache, whereas the
remainder of the response message MAY be. remainder of the response message MAY be.
Note: This usage of the word private only controls where the Note: This usage of the word private only controls where the
response may be stored, and cannot ensure the privacy of the response may be stored, and 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 recieved; 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 caching even by caches that have been configured to return prevent caching even by caches that have been configured to return
stale responses. stale responses.
skipping to change at page 21, line 17 skipping to change at page 21, line 17
with the listed response headers. That is, the specified field- with the listed response headers. That is, the specified field-
name(s) MUST NOT be sent in the response to a subsequent request name(s) MUST NOT be sent in the response to a subsequent request
without successful validation on the origin server. This allows without successful validation on the origin server. This allows
an origin server to prevent the re-use of certain header fields in an origin server to prevent the re-use of certain header fields in
a response, while still allowing caching of the rest of the a response, while still allowing caching of the rest of the
response. 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 recieved; 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 non-shared 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
skipping to change at page 23, line 42 skipping to change at page 23, line 42
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]; it MUST be sent in 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 HTTP/1.1 servers SHOULD NOT send Expires dates more than one year in
the future. the future.
HTTP/1.1 clients and caches MUST treat other invalid date formats, HTTP/1.1 clients and caches MUST treat other invalid date formats,
especially including the value "0", as in the past (i.e., "already especially including the value "0", as in the past (i.e., "already
expired"). expired").
skipping to change at page 24, line 29 skipping to change at page 24, line 29
When the no-cache directive is present in a request message, an When the no-cache directive is present in a request message, an
application SHOULD forward the request toward the origin server even application SHOULD forward the request toward the origin server even
if it has a cached copy of what is being requested. This pragma if it has a cached copy of what is being requested. This pragma
directive has the same semantics as the no-cache response directive directive has the same semantics as the no-cache response directive
(see Section 3.2.2) and is defined here for backward compatibility (see Section 3.2.2) and is defined here for backward compatibility
with HTTP/1.0. Clients SHOULD include both header fields when a no- with HTTP/1.0. Clients SHOULD include both header fields when a no-
cache request is sent to a server not known to be HTTP/1.1 compliant. cache request is sent to a server not known to be HTTP/1.1 compliant.
HTTP/1.1 caches SHOULD treat "Pragma: no-cache" as if the client had HTTP/1.1 caches SHOULD treat "Pragma: no-cache" as if the client had
sent "Cache-Control: no-cache". sent "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 response-
header field is not actually specified, it does not provide a header field is not actually specified, it does not provide a
reliable replacement for "Cache-Control: no-cache" in a response. reliable 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" response-header field conveys the set of request-header
fields that were used to select the representation. fields that were 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 satisdy a given request; see Section 2.6. response can be used to satisfy a given request; see Section 2.6.
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.6. validation; see Section 2.6.
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
skipping to change at page 25, line 41 skipping to change at page 25, line 41
The "Warning" general-header field is used to carry additional The "Warning" general-header field is used to carry additional
information about the status or transformation of a message that information about the status or transformation of a message that
might not be reflected in the message. This information is typically might not be reflected in the message. This information is typically
used to warn about possible incorrectness introduced by caching used to warn about possible incorrectness introduced by caching
operations or transformations applied to the entity body of the operations or transformations applied to the entity body of the
message. 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,
distinguish these responses from true failures. distinguishes these responses from true failures.
Warning headers can in general be applied to any message, however Warning headers can in general be applied to any message, however
some warn-codes are specific to caches and can only be applied to some warn-codes are specific to caches and can only be applied to
response messages. response messages.
Warning = "Warning" ":" OWS Warning-v Warning = "Warning" ":" OWS Warning-v
Warning-v = 1#warning-value Warning-v = 1#warning-value
warning-value = warn-code SP warn-agent SP warn-text warning-value = warn-code SP warn-agent SP warn-text
[SP warn-date] [SP warn-date]
skipping to change at page 28, line 25 skipping to change at page 28, line 25
what the user saw at the time when the resource was retrieved. what the user saw at the time when the resource was retrieved.
By default, an expiration time does not apply to history mechanisms. By default, an expiration time does not apply to history mechanisms.
If the entity is still in storage, a history mechanism SHOULD display If the entity is still in storage, a history mechanism SHOULD display
it even if the entity has expired, unless the user has specifically it even if the entity has expired, unless the user has specifically
configured the agent to refresh expired history documents. configured the agent to refresh expired history documents.
This is not to be construed to prohibit the history mechanism from This is not to be construed to prohibit the history mechanism from
telling the user that a view might be stale. telling the user that a view might be stale.
Note: if history list mechanisms unnecessarily prevent users from Note: If history list mechanisms unnecessarily prevent users from
viewing stale resources, this will tend to force service authors viewing stale resources, this will tend to force service authors
to avoid using HTTP expiration controls and cache controls when to avoid using HTTP expiration controls and cache controls when
they would otherwise like to. Service authors may consider it they would otherwise like to. Service authors may consider it
important that users not be presented with error messages or important that users not be presented with error messages or
warning messages when they use navigation controls (such as BACK) warning messages when they use navigation controls (such as BACK)
to view previously fetched resources. Even though sometimes such to view previously fetched resources. Even though sometimes such
resources ought not be cached, or ought to expire quickly, user resources ought not be cached, or ought to expire quickly, user
interface considerations may force service authors to resort to interface considerations may force service authors to resort to
other means of preventing caching (e.g. "once-only" URLs) in order other means of preventing caching (e.g. "once-only" URLs) in order
not to suffer the effects of improperly functioning history not to suffer the effects of improperly functioning history
skipping to change at page 29, line 42 skipping to change at page 29, line 42
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-08 and Message Parsing",
(work in progress), October 2009. draft-ietf-httpbis-p1-messaging-latest (work in progress),
February 2010.
[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-08 (work in Semantics", draft-ietf-httpbis-p2-semantics-latest (work
progress), October 2009. in progress), February 2010.
[Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part3] 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 3: Message Payload and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload
and Content Negotiation", draft-ietf-httpbis-p3-payload-08 and Content Negotiation",
(work in progress), October 2009. draft-ietf-httpbis-p3-payload-latest (work in progress),
February 2010.
[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-08 (work in Requests", draft-ietf-httpbis-p4-conditional-latest (work
progress), October 2009. in progress), February 2010.
[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-08 (work Partial Responses", draft-ietf-httpbis-p5-range-latest
in progress), October 2009. (work in progress), February 2010.
[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-08 (work in progress), draft-ietf-httpbis-p7-auth-latest (work in progress),
October 2009. February 2010.
[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 21 skipping to change at page 36, line 21
o <http://tools.ietf.org/wg/httpbis/trac/ticket/167>: "Content- o <http://tools.ietf.org/wg/httpbis/trac/ticket/167>: "Content-
Location on 304 responses" Location on 304 responses"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/169>: "private and o <http://tools.ietf.org/wg/httpbis/trac/ticket/169>: "private and
no-cache CC directives with headers" no-cache CC directives with headers"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/187>: "RFC2047 and o <http://tools.ietf.org/wg/httpbis/trac/ticket/187>: "RFC2047 and
warn-text" warn-text"
C.10. Since draft-ietf-httpbis-p6-cache-08
Affected issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/199>: Status codes
and caching
Index Index
A A
age 6 age 6
Age header 17 Age header 17
C C
cache 5 cache 5
Cache Directives Cache Directives
max-age 18, 22 max-age 19, 22
max-stale 19 max-stale 19
min-fresh 19 min-fresh 19
must-revalidate 21 must-revalidate 21
no-cache 18, 20 no-cache 18, 20
no-store 18, 21 no-store 18, 21
no-transform 19, 22 no-transform 19, 22
only-if-cached 19 only-if-cached 19
private 20 private 20
proxy-revalidate 21 proxy-revalidate 21
public 20 public 20
skipping to change at page 37, line 44 skipping to change at page 37, line 51
Age 17 Age 17
Cache-Control 17 Cache-Control 17
Expires 23 Expires 23
Pragma 24 Pragma 24
Vary 24 Vary 24
Warning 25 Warning 25
heuristic expiration time 5 heuristic expiration time 5
M M
max-age max-age
Cache Directive 18, 22 Cache Directive 19, 22
max-stale max-stale
Cache Directive 19 Cache Directive 19
min-fresh min-fresh
Cache Directive 19 Cache Directive 19
must-revalidate must-revalidate
Cache Directive 21 Cache Directive 21
N N
no-cache no-cache
Cache Directive 18, 20 Cache Directive 18, 20
no-store no-store
Cache Directive 18, 21 Cache Directive 18, 21
no-transform no-transform
Cache Directive 19, 22 Cache Directive 19, 22
O O
only-if-cached only-if-cached
 End of changes. 36 change blocks. 
73 lines changed or deleted 111 lines changed or added

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