draft-ietf-httpbis-p6-cache-18.txt   draft-ietf-httpbis-p6-cache-19.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) Y. Lafon, Ed.
Intended status: Standards Track Alcatel-Lucent Intended status: Standards Track W3C
Expires: July 7, 2012 J. Mogul Expires: September 13, 2012 M. Nottingham, Ed.
HP
H. Frystyk
Microsoft
L. Masinter
Adobe
P. Leach
Microsoft
T. Berners-Lee
W3C/MIT
Y. Lafon, Ed.
W3C
M. Nottingham, Ed.
Rackspace Rackspace
J. Reschke, Ed. J. Reschke, Ed.
greenbytes greenbytes
January 4, 2012 March 12, 2012
HTTP/1.1, part 6: Caching HTTP/1.1, part 6: Caching
draft-ietf-httpbis-p6-cache-18 draft-ietf-httpbis-p6-cache-19
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is an application-level The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypertext information protocol for distributed, collaborative, hypertext information
systems. HTTP has been in use by the World Wide Web global systems. HTTP has been in use by the World Wide Web global
information initiative since 1990. This document is Part 6 of the information initiative since 1990. This document is Part 6 of the
seven-part specification that defines the protocol referred to as seven-part specification that defines the protocol referred to as
"HTTP/1.1" and, taken together, obsoletes RFC 2616. "HTTP/1.1" and, taken together, obsoletes RFC 2616.
skipping to change at page 2, line 6 skipping to change at page 1, line 40
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.19. The changes in this draft are summarized in Appendix C.20.
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 July 7, 2012. This Internet-Draft will expire on September 13, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 24 skipping to change at page 3, line 11
Specification . . . . . . . . . . . . . . . . . . . . 8 Specification . . . . . . . . . . . . . . . . . . . . 8
1.5. Delta Seconds . . . . . . . . . . . . . . . . . . . . . . 8 1.5. Delta Seconds . . . . . . . . . . . . . . . . . . . . . . 8
2. Cache Operation . . . . . . . . . . . . . . . . . . . . . . . 8 2. Cache Operation . . . . . . . . . . . . . . . . . . . . . . . 8
2.1. Response Cacheability . . . . . . . . . . . . . . . . . . 9 2.1. Response Cacheability . . . . . . . . . . . . . . . . . . 9
2.2. Constructing Responses from Caches . . . . . . . . . . . . 10 2.2. Constructing Responses from Caches . . . . . . . . . . . . 10
2.3. Freshness Model . . . . . . . . . . . . . . . . . . . . . 12 2.3. Freshness Model . . . . . . . . . . . . . . . . . . . . . 12
2.3.1. Calculating Freshness Lifetime . . . . . . . . . . . . 13 2.3.1. Calculating Freshness Lifetime . . . . . . . . . . . . 13
2.3.2. Calculating Age . . . . . . . . . . . . . . . . . . . 14 2.3.2. Calculating Age . . . . . . . . . . . . . . . . . . . 14
2.3.3. Serving Stale Responses . . . . . . . . . . . . . . . 16 2.3.3. Serving Stale Responses . . . . . . . . . . . . . . . 16
2.4. Validation Model . . . . . . . . . . . . . . . . . . . . . 16 2.4. Validation Model . . . . . . . . . . . . . . . . . . . . . 16
2.4.1. Freshening Responses . . . . . . . . . . . . . . . . . 17 2.4.1. Freshening Responses with 304 Not Modified . . . . . . 17
2.5. Request Methods that Invalidate . . . . . . . . . . . . . 18 2.5. Updating Caches with HEAD Responses . . . . . . . . . . . 18
2.6. Shared Caching of Authenticated Responses . . . . . . . . 18 2.6. Request Methods that Invalidate . . . . . . . . . . . . . 18
2.7. Caching Negotiated Responses . . . . . . . . . . . . . . . 19 2.7. Shared Caching of Authenticated Responses . . . . . . . . 19
2.8. Combining Partial Content . . . . . . . . . . . . . . . . 20 2.8. Caching Negotiated Responses . . . . . . . . . . . . . . . 19
3. Header Field Definitions . . . . . . . . . . . . . . . . . . . 20 2.9. Combining Partial Content . . . . . . . . . . . . . . . . 20
3.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3. Header Field Definitions . . . . . . . . . . . . . . . . . . . 21
3.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 21 3.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 21
3.2.1. Request Cache-Control Directives . . . . . . . . . . . 21 3.2.1. Request Cache-Control Directives . . . . . . . . . . . 22
3.2.2. Response Cache-Control Directives . . . . . . . . . . 23 3.2.2. Response Cache-Control Directives . . . . . . . . . . 24
3.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 26 3.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 26
3.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.6. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.6. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.6.1. 110 Response is Stale . . . . . . . . . . . . . . . . 31 3.6.1. 110 Response is Stale . . . . . . . . . . . . . . . . 31
3.6.2. 111 Revalidation Failed . . . . . . . . . . . . . . . 31 3.6.2. 111 Revalidation Failed . . . . . . . . . . . . . . . 31
3.6.3. 112 Disconnected Operation . . . . . . . . . . . . . . 31 3.6.3. 112 Disconnected Operation . . . . . . . . . . . . . . 31
3.6.4. 113 Heuristic Expiration . . . . . . . . . . . . . . . 31 3.6.4. 113 Heuristic Expiration . . . . . . . . . . . . . . . 32
3.6.5. 199 Miscellaneous Warning . . . . . . . . . . . . . . 31 3.6.5. 199 Miscellaneous Warning . . . . . . . . . . . . . . 32
3.6.6. 214 Transformation Applied . . . . . . . . . . . . . . 31 3.6.6. 214 Transformation Applied . . . . . . . . . . . . . . 32
3.6.7. 299 Miscellaneous Persistent Warning . . . . . . . . . 31 3.6.7. 299 Miscellaneous Persistent Warning . . . . . . . . . 32
3.6.8. Warn Code Extensions . . . . . . . . . . . . . . . . . 32 3.6.8. Warn Code Extensions . . . . . . . . . . . . . . . . . 32
3.7. History Lists . . . . . . . . . . . . . . . . . . . . . . 32 4. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 32
3.8. IANA Considerations . . . . . . . . . . . . . . . . . . . 32 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
3.8.1. Cache Directive Registry . . . . . . . . . . . . . . . 32 5.1. Cache Directive Registry . . . . . . . . . . . . . . . . . 33
3.8.2. Warn Code Registry . . . . . . . . . . . . . . . . . . 33 5.2. Warn Code Registry . . . . . . . . . . . . . . . . . . . . 33
3.9. Header Field Registration . . . . . . . . . . . . . . . . 33 5.3. Header Field Registration . . . . . . . . . . . . . . . . 34
4. Security Considerations . . . . . . . . . . . . . . . . . . . 34 6. Security Considerations . . . . . . . . . . . . . . . . . . . 34
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.1. Normative References . . . . . . . . . . . . . . . . . . . 34 8.1. Normative References . . . . . . . . . . . . . . . . . . . 35
6.2. Informative References . . . . . . . . . . . . . . . . . . 35 8.2. Informative References . . . . . . . . . . . . . . . . . . 35
Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 35 Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 36
Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 36 Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 36
Appendix C. Change Log (to be removed by RFC Editor before Appendix C. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 37 publication) . . . . . . . . . . . . . . . . . . . . 37
C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 37 C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 38
C.2. Since draft-ietf-httpbis-p6-cache-00 . . . . . . . . . . . 37 C.2. Since draft-ietf-httpbis-p6-cache-00 . . . . . . . . . . . 38
C.3. Since draft-ietf-httpbis-p6-cache-01 . . . . . . . . . . . 38 C.3. Since draft-ietf-httpbis-p6-cache-01 . . . . . . . . . . . 38
C.4. Since draft-ietf-httpbis-p6-cache-02 . . . . . . . . . . . 38 C.4. Since draft-ietf-httpbis-p6-cache-02 . . . . . . . . . . . 39
C.5. Since draft-ietf-httpbis-p6-cache-03 . . . . . . . . . . . 39 C.5. Since draft-ietf-httpbis-p6-cache-03 . . . . . . . . . . . 39
C.6. Since draft-ietf-httpbis-p6-cache-04 . . . . . . . . . . . 39 C.6. Since draft-ietf-httpbis-p6-cache-04 . . . . . . . . . . . 39
C.7. Since draft-ietf-httpbis-p6-cache-05 . . . . . . . . . . . 39 C.7. Since draft-ietf-httpbis-p6-cache-05 . . . . . . . . . . . 39
C.8. Since draft-ietf-httpbis-p6-cache-06 . . . . . . . . . . . 40 C.8. Since draft-ietf-httpbis-p6-cache-06 . . . . . . . . . . . 40
C.9. Since draft-ietf-httpbis-p6-cache-07 . . . . . . . . . . . 40 C.9. Since draft-ietf-httpbis-p6-cache-07 . . . . . . . . . . . 40
C.10. Since draft-ietf-httpbis-p6-cache-08 . . . . . . . . . . . 40 C.10. Since draft-ietf-httpbis-p6-cache-08 . . . . . . . . . . . 40
C.11. Since draft-ietf-httpbis-p6-cache-09 . . . . . . . . . . . 41 C.11. Since draft-ietf-httpbis-p6-cache-09 . . . . . . . . . . . 41
C.12. Since draft-ietf-httpbis-p6-cache-10 . . . . . . . . . . . 41 C.12. Since draft-ietf-httpbis-p6-cache-10 . . . . . . . . . . . 41
C.13. Since draft-ietf-httpbis-p6-cache-11 . . . . . . . . . . . 41 C.13. Since draft-ietf-httpbis-p6-cache-11 . . . . . . . . . . . 42
C.14. Since draft-ietf-httpbis-p6-cache-12 . . . . . . . . . . . 42 C.14. Since draft-ietf-httpbis-p6-cache-12 . . . . . . . . . . . 42
C.15. Since draft-ietf-httpbis-p6-cache-13 . . . . . . . . . . . 42 C.15. Since draft-ietf-httpbis-p6-cache-13 . . . . . . . . . . . 42
C.16. Since draft-ietf-httpbis-p6-cache-14 . . . . . . . . . . . 42 C.16. Since draft-ietf-httpbis-p6-cache-14 . . . . . . . . . . . 42
C.17. Since draft-ietf-httpbis-p6-cache-15 . . . . . . . . . . . 42 C.17. Since draft-ietf-httpbis-p6-cache-15 . . . . . . . . . . . 43
C.18. Since draft-ietf-httpbis-p6-cache-16 . . . . . . . . . . . 43 C.18. Since draft-ietf-httpbis-p6-cache-16 . . . . . . . . . . . 43
C.19. Since draft-ietf-httpbis-p6-cache-17 . . . . . . . . . . . 43 C.19. Since draft-ietf-httpbis-p6-cache-17 . . . . . . . . . . . 43
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 C.20. Since draft-ietf-httpbis-p6-cache-18 . . . . . . . . . . . 43
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
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 45 skipping to change at page 7, line 45
define specific error handling mechanisms, except in cases where it define specific error handling mechanisms, except in cases where it
has direct impact on security. This is because different uses of the has direct impact on security. This is because different uses of the
protocol require different error handling strategies; for example, a protocol require different error handling strategies; for example, a
Web browser may wish to transparently recover from a response where Web browser may wish to transparently recover from a response where
the Location header field doesn't parse according to the ABNF, the Location header field doesn't parse according to the ABNF,
whereby in a systems control protocol using HTTP, this type of error whereby in a systems control protocol using HTTP, this type of error
recovery could lead to dangerous consequences. recovery could lead to dangerous consequences.
1.4. Syntax Notation 1.4. Syntax Notation
This specification uses the ABNF syntax defined in Section 1.2 of This specification uses the Augmented Backus-Naur Form (ABNF)
[Part1] (which extends the syntax defined in [RFC5234] with a list notation of [RFC5234] with the list rule extension defined in Section
rule). Appendix B shows the collected ABNF, with the list rule 1.2 of [Part1]. Appendix B shows the collected ABNF with the list
expanded. rule expanded.
The following core rules are included by reference, as defined in The following core rules are included by reference, as defined in
[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
(CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit
sequence of data), SP (space), and VCHAR (any visible US-ASCII sequence of data), SP (space), and VCHAR (any visible US-ASCII
character). character).
1.4.1. Core Rules 1.4.1. Core Rules
The core rules below are defined in [Part1]: The core rules below are defined in [Part1]:
OWS = <OWS, defined in [Part1], Section 1.2.2> OWS = <OWS, defined in [Part1], Section 3.2.1>
quoted-string = <quoted-string, defined in [Part1], Section 3.2.3> quoted-string = <quoted-string, defined in [Part1], Section 3.2.4>
token = <token, defined in [Part1], Section 3.2.3> token = <token, defined in [Part1], Section 3.2.4>
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 [Part2], Section 8> HTTP-date = <HTTP-date, defined in [Part2], Section 8>
port = <port, defined in [Part1], Section 2.7> port = <port, defined in [Part1], Section 2.7>
pseudonym = <pseudonym, defined in [Part1], Section 8.8> pseudonym = <pseudonym, defined in [Part1], Section 6.2>
uri-host = <uri-host, defined in [Part1], Section 2.7> uri-host = <uri-host, defined in [Part1], Section 2.7>
1.5. Delta Seconds 1.5. Delta Seconds
The delta-seconds rule specifies a non-negative integer, representing The delta-seconds rule specifies a non-negative integer, representing
time in seconds. time in seconds.
delta-seconds = 1*DIGIT delta-seconds = 1*DIGIT
If an implementation receives a delta-seconds value larger than the If an implementation receives a delta-seconds value larger than the
skipping to change at page 9, line 21 skipping to change at page 9, line 21
caching and defines something suitable for use as a cache key. caching and defines something suitable for use as a cache key.
The default cache key consists of the request method and target URI. The default cache key consists of the request method and target URI.
However, since HTTP caches in common use today are typically limited However, since HTTP caches in common use today are typically limited
to caching responses to GET, most implementations simply decline to caching responses to GET, most implementations simply decline
other methods and use only the URI as the key. other methods and use only the URI as the key.
If a request target is subject to content negotiation, its cache If a request target is subject to content negotiation, its cache
entry might consist of multiple stored responses, each differentiated entry might consist of multiple stored responses, each differentiated
by a secondary key for the values of the original request's selecting by a secondary key for the values of the original request's selecting
header fields (Section 2.7). header fields (Section 2.8).
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
o the response status code is understood by the cache, 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 header fields, and in request or response header fields, and
o the "private" cache response directive (see Section 3.2.2 does not o the "private" cache response directive (see Section 3.2.2) does
appear in the response, if the cache is shared, and not appear in the response, if the cache is shared, and
o the "Authorization" header field (see Section 4.1 of [Part7]) does o the "Authorization" header field (see Section 4.1 of [Part7]) does
not appear in the request, if the cache is shared, unless the not appear in the request, if the cache is shared, unless the
response explicitly allows it (see Section 2.6), and response explicitly allows it (see Section 2.7), and
o the response either: o the response either:
* contains an Expires header field (see Section 3.3), or * contains an Expires header field (see Section 3.3), or
* contains a max-age response cache directive (see * contains a max-age response cache directive (see
Section 3.2.2), or Section 3.2.2), or
* 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
skipping to change at page 10, line 27 skipping to change at page 10, line 27
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.
A response message is considered complete when all of the octets A response message is considered complete when all of the octets
indicated by the message framing ([Part1]) are received prior to the indicated by the message framing ([Part1]) are received prior to the
connection being closed. If the request is GET, the response status connection being closed. If the request is GET, the response status
is 200 (OK), and the entire response header block has been received, is 200 (OK), and the entire response header block has been received,
a cache MAY store an incomplete response message-body if the cache a cache MAY store an incomplete response message body if the cache
entry is recorded as incomplete. Likewise, a 206 (Partial Content) entry is recorded as incomplete. Likewise, a 206 (Partial Content)
response MAY be stored as if it were an incomplete 200 (OK) cache response MAY be stored as if it were an incomplete 200 (OK) cache
entry. However, a cache MUST NOT store incomplete or partial content entry. However, a cache MUST NOT store incomplete or partial content
responses if it does not support the Range and Content-Range header responses if it does not support the Range and Content-Range header
fields or if it does not understand the range units used in those fields or if it does not understand the range units used in those
fields. fields.
A cache MAY complete a stored incomplete response by making a A cache MAY complete a stored incomplete response by making a
subsequent range request ([Part5]) and combining the successful subsequent range request ([Part5]) and combining the successful
response with the stored entry, as defined in Section 2.8. A cache response with the stored entry, as defined in Section 2.9. A cache
MUST NOT use an incomplete response to answer requests unless the MUST NOT use an incomplete response to answer requests unless the
response has been made complete or the request is partial and response has been made complete or the request is partial and
specifies a range that is wholly within the incomplete response. A specifies a range that is wholly within the incomplete response. A
cache MUST NOT send a partial response to a client without explicitly cache MUST NOT send a partial response to a client without explicitly
marking it as such using the 206 (Partial Content) status code. marking it as such using the 206 (Partial Content) status code.
2.2. Constructing Responses from Caches 2.2. Constructing Responses from Caches
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 5.5 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 header fields nominated by the stored response (if any) o selecting header fields nominated by the stored response (if any)
match those presented (see Section 2.7), and match those presented (see Section 2.8), and
o the presented request does not contain the no-cache pragma o the presented request does not contain the no-cache pragma
(Section 3.4), nor the no-cache cache directive (Section 3.2.1), (Section 3.4), nor the no-cache cache directive (Section 3.2.1),
unless the stored response is successfully validated unless the stored response is successfully validated
(Section 2.4), and (Section 2.4), and
o the stored response does not contain the no-cache cache directive o the stored response does not contain the no-cache cache directive
(Section 3.2.2), unless it is successfully validated (Section 3.2.2), unless it is successfully validated
(Section 2.4), and (Section 2.4), and
skipping to change at page 11, line 42 skipping to change at page 11, line 42
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 6.1.1 of [Part2]) to the origin server; i.e., a cache must (Section 6.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.6.
When more than one suitable response is stored, a cache MUST use the When more than one suitable response is stored, a cache MUST use the
most recent response (as determined by the Date header field). It most recent response (as determined by the Date header field). It
can 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
skipping to change at page 12, line 46 skipping to change at page 12, line 46
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 can influence freshness calculation -- either Additionally, clients can influence freshness calculation -- either
constraining it relaxing it -- by using the max-age and min-fresh constraining it relaxing it -- by using the max-age and min-fresh
request cache directives. See Section 3.2.1 for details. request cache directives. See Section 3.2.1 for details.
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 3.7 for an explanation of the difference resource. See Section 4 for an explanation of the difference between
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:
o If the cache is shared and the s-maxage response cache directive o If the cache is shared and the s-maxage response cache directive
(Section 3.2.2) is present, use its value, or (Section 3.2.2) is present, use its value, or
o If the max-age response cache directive (Section 3.2.2) is o If the max-age response cache directive (Section 3.2.2) is
skipping to change at page 14, line 29 skipping to change at page 14, line 29
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
HTTP/1.1 requires origin servers to send a Date header field, if HTTP/1.1 requires origin servers to send a Date header field, if
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.2 of [Part2] for the definition of the operations. See Section 10.2 of [Part2] 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". A cache SHOULD use NTP ([RFC1305]) performing the calculation". A cache SHOULD use NTP ([RFC1305])
or some similar protocol to synchronize its clocks to a globally or some similar protocol to synchronize its clocks to a globally
accurate time standard. accurate time standard.
skipping to change at page 16, line 43 skipping to change at page 16, line 43
the requesting client, and the received response is no longer fresh, the requesting client, and the received response is no longer fresh,
the cache can forward it to the requesting client without adding a the cache can 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 shouldn't attempt to validate a response simply fields). A cache shouldn't 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.8), 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, a cache adds an If-Modified- When sending such a conditional request, a cache adds an If-Modified-
Since header field whose value is that of the Last-Modified header Since header field whose value is that of the Last-Modified header
field from the selected (see Section 2.7) stored response, if field from the selected (see Section 2.8) stored response, if
available. available.
Additionally, a cache can add an If-None-Match header field whose Additionally, a cache can add an If-None-Match header field whose
value is that of the ETag header field(s) from all responses stored value is that of the ETag header field(s) from all responses stored
for the requested URI, if present. However, if any of the stored for the requested URI, if present. However, if any of the stored
responses contains only partial content, the cache shouldn't include responses contains only partial content, the cache shouldn't include
its entity-tag 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.
Cache handling of a response to a conditional request is dependent Cache handling of a response to a conditional request is dependent
skipping to change at page 17, line 30 skipping to change at page 17, line 30
none of the stored responses nominated in the conditional request none of the stored responses nominated in the conditional request
is suitable. Instead, the cache can use the full response to is suitable. Instead, the cache can use the full response to
satisfy the request and MAY replace the stored response(s). satisfy the request and MAY replace the stored response(s).
o However, if a cache receives a 5xx response while attempting to o However, if a cache receives a 5xx response while attempting to
validate a response, it can either forward this response to the validate a response, it can either forward this response to the
requesting client, or act as if the server failed to respond. In requesting client, or act as if the server failed to respond. In
the latter case, it can return a previously stored response (see the latter case, it can return a previously stored response (see
Section 2.3.3). Section 2.3.3).
2.4.1. Freshening Responses 2.4.1. Freshening Responses with 304 Not Modified
When a cache receives a 304 (Not Modified) response and already has When a cache receives a 304 (Not Modified) response and already has
one or more stored 200 (OK) responses for the same cache key, the one or more stored 200 (OK) responses for the same cache key, the
cache needs to identify which of the stored responses are updated by cache needs to identify which of the stored responses are updated by
this new response and then update the stored response(s) with the new this new response and then update the stored response(s) with the new
information provided in the 304 response. information provided in the 304 response.
o If the new response contains a strong validator, then that strong o If the new response contains a strong validator, then that strong
validator identifies the selected representation. All of the validator identifies the selected representation. All of the
stored responses with the same strong validator are selected. If stored responses with the same strong validator are selected. If
skipping to change at page 18, line 17 skipping to change at page 18, line 17
o delete any Warning header fields in the stored response with warn- o delete any Warning header fields in the stored response with warn-
code 1xx (see Section 3.6); code 1xx (see Section 3.6);
o retain any Warning header fields in the stored response with warn- o retain any Warning header fields in the stored response with warn-
code 2xx; and, code 2xx; and,
o use other header fields provided in the 304 response to replace o use other header fields provided in the 304 response to replace
all instances of the corresponding header fields in the stored all instances of the corresponding header fields in the stored
response. response.
2.5. Request Methods that Invalidate 2.5. Updating Caches with HEAD Responses
A response to the HEAD method is identical to what an equivalent
request made with a GET would have been, except it lacks a body.
This property of HEAD responses is used to both invalidate and update
cached GET responses.
If one or more stored GET responses can be selected (as per
Section 2.8) for a HEAD request, and the Content-Length, ETag or
Last-Modified value of a HEAD response differs from that in a
selected GET response, the cache MUST consider that selected response
to be stale.
If the Content-Length, ETag and Last-Modified values of a HEAD
response (when present) are the same as that in a selected GET
response (as per Section 2.8), the cache SHOULD update the remaining
headers in the stored response using the following rules:
o delete any Warning header fields in the stored response with warn-
code 1xx (see Section 3.6);
o retain any Warning header fields in the stored response with warn-
code 2xx; and,
o use other header fields provided in the response to replace all
instances of the corresponding header fields in the stored
response.
2.6. Request Methods that Invalidate
Because unsafe request methods (Section 6.1.1 of [Part2]) such as Because unsafe request methods (Section 6.1.1 of [Part2]) such as
PUT, POST or DELETE have the potential for changing state on the PUT, POST or DELETE have the potential for changing state on the
origin server, intervening caches can use them to keep their contents origin server, intervening caches can use them to keep their contents
up-to-date. up-to-date.
A cache MUST invalidate the effective Request URI (Section 4.3 of A cache MUST invalidate the effective Request URI (Section 5.5 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 a non-error response to a request response header fields (if present) when a non-error response to a
with an unsafe method is received. request with an unsafe method is received.
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 response header field if the host part of that URI
from the host part in the effective request URI (Section 4.3 of differs from the host part in the effective request URI (Section 5.5
[Part1]). This helps prevent denial of service attacks. of [Part1]). This helps prevent denial of service attacks.
A cache MUST invalidate the effective request URI (Section 4.3 of A cache MUST invalidate the effective request URI (Section 5.5 of
[Part1]) when it receives a non-error response to a request with a [Part1]) when it receives a non-error response to a request with a
method whose safety is unknown. method whose safety is unknown.
Here, a "non-error response" is one with a 2xx or 3xx status code. Here, a "non-error response" is one with a 2xx or 3xx status code.
"Invalidate" means that the cache will either remove all stored "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.7. Shared Caching of Authenticated Responses
A shared cache 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.8. 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 header fields nominated by that response unless all of the selecting header fields nominated by
the Vary header field match in both the original request (i.e., that the Vary header field match in both the original request (i.e., that
associated with the stored response), and the presented request. associated with the stored response), and the presented request.
The selecting header fields from two requests are defined to match if The selecting header fields from two requests are defined to match if
and only if those in the first request can be transformed to those in and only if those in the first request can be transformed to those in
the second request by applying any of the following: the second request by applying any of the following:
skipping to change at page 20, line 13 skipping to change at page 20, line 41
the selected response. the selected response.
If multiple selected responses are available, the most recent If multiple selected responses are available, the most recent
response (as determined by the Date header field) is used; see response (as determined by the Date header field) is used; see
Section 2.2. Section 2.2.
If no selected response is available, the cache can forward the If no selected response is available, the cache can 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 Partial Content 2.9. Combining Partial Content
A response might transfer only a partial representation if the A response might transfer only a partial representation if the
connection closed prematurely or if the request used one or more connection closed prematurely or if the request used one or more
Range specifiers ([Part5]). After several such transfers, a cache Range specifiers ([Part5]). After several such transfers, a cache
might have received several ranges of the same representation. A might have received several ranges of the same representation. A
cache MAY combine these ranges into a single stored response, and cache MAY combine these ranges into a single stored response, and
reuse that response to satisfy later requests, if they all share the reuse that response to satisfy later requests, if they all share the
same strong validator and the cache complies with the client same strong validator and the cache complies with the client
requirements in Section 4 of [Part5]. requirements in Section 4.2 of [Part5].
When combining the new response with one or more stored responses, a When combining the new response with one or more stored responses, a
cache MUST: cache MUST:
o delete any Warning header fields in the stored response with warn- o delete any Warning header fields in the stored response with warn-
code 1xx (see Section 3.6); code 1xx (see Section 3.6);
o retain any Warning header fields in the stored response with warn- o retain any Warning header fields in the stored response with warn-
code 2xx; and, code 2xx; and,
skipping to change at page 23, line 43 skipping to change at page 24, line 23
/ "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 a response whose The public response directive indicates that a response whose
associated request contains an 'Authentication' header MAY be associated request contains an 'Authentication' header MAY be
stored (see Section 2.6). stored (see Section 2.7).
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 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, a shared cache with the listed response header fields. That is, a shared cache
MUST NOT store the specified field-names(s), whereas it MAY store MUST NOT store the specified field-names(s), whereas it MAY store
the remainder of the response message. 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, then a cache MAY use the response to satisfy a subsequent
with the listed response header fields. That is, a cache MUST NOT request, subject to any other restrictions on caching. However,
send the specified field-name(s) in the response to a subsequent any header fields in the response that have the field-name(s)
request without successful validation on the origin server. This listed MUST NOT be sent in the response to a subsequent request
without successful revalidation with 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.
skipping to change at page 27, line 9 skipping to change at page 27, line 35
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
Values to be added to this name space are subject to IETF review Values to be added to this name space require IETF Review (see
([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>.
3.3. Expires 3.3. Expires
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.
skipping to change at page 29, line 4 skipping to change at page 29, line 29
Note: Because the meaning of "Pragma: no-cache" in responses is Note: Because the meaning of "Pragma: no-cache" in responses is
not specified, it does not provide a reliable replacement for not specified, it does not provide a reliable replacement for
"Cache-Control: no-cache" in them. "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.8.
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.8.
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 = "*" / 1#field-name Vary = "*" / 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 header fields. the selecting header fields.
skipping to change at page 32, line 17 skipping to change at page 32, line 43
The HTTP Warn Code Registry defines the name space for warn codes. The HTTP Warn Code Registry defines the name space for warn codes.
A registration MUST include the following fields: A registration MUST include the following fields:
o Warn Code (3 digits) o Warn Code (3 digits)
o Short Description o Short Description
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 require IETF Review (see
([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-warn-codes>. <http://www.iana.org/assignments/http-warn-codes>.
3.7. 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
history lists, that can be used to redisplay a representation history lists, that can be used to redisplay a representation
retrieved earlier in a session. retrieved earlier in a session.
The freshness model (Section 2.3) does not necessarily apply to The freshness model (Section 2.3) does not necessarily apply to
history mechanisms. I.e., a history mechanism can display a previous history mechanisms. I.e., a history mechanism can display a previous
representation even if it has expired. representation even if it has expired.
This does not prohibit the history mechanism from telling the user This does not prohibit the history mechanism from telling the user
that a view might be stale, or from honoring cache directives (e.g., that a view might be stale, or from honoring cache directives (e.g.,
Cache-Control: no-store). Cache-Control: no-store).
3.8. IANA Considerations 5. IANA Considerations
3.8.1. Cache Directive Registry 5.1. Cache Directive Registry
The registration procedure for HTTP Cache Directives is defined by The registration procedure for HTTP Cache Directives is defined by
Section 3.2.3 of this document. Section 3.2.3 of this document.
The HTTP Cache Directive Registry shall be created at The HTTP Cache Directive Registry shall be created at
<http://www.iana.org/assignments/http-cache-directives> and be <http://www.iana.org/assignments/http-cache-directives> and be
populated with the registrations below: populated with the registrations below:
+------------------------+------------------------------+ +------------------------+------------------------------+
| Cache Directive | Reference | | Cache Directive | Reference |
skipping to change at page 33, line 24 skipping to change at page 33, line 44
| no-transform | Section 3.2.1, Section 3.2.2 | | no-transform | Section 3.2.1, Section 3.2.2 |
| only-if-cached | Section 3.2.1 | | only-if-cached | Section 3.2.1 |
| private | Section 3.2.2 | | private | Section 3.2.2 |
| proxy-revalidate | Section 3.2.2 | | proxy-revalidate | Section 3.2.2 |
| public | Section 3.2.2 | | public | Section 3.2.2 |
| s-maxage | Section 3.2.2 | | s-maxage | Section 3.2.2 |
| stale-if-error | [RFC5861], Section 4 | | stale-if-error | [RFC5861], Section 4 |
| stale-while-revalidate | [RFC5861], Section 3 | | stale-while-revalidate | [RFC5861], Section 3 |
+------------------------+------------------------------+ +------------------------+------------------------------+
3.8.2. Warn Code Registry 5.2. Warn Code Registry
The registration procedure for HTTP Warn Codes is defined by The registration procedure for HTTP Warn Codes is defined by
Section 3.6.8 of this document. Section 3.6.8 of this document.
The HTTP Warn Code Registry shall be created at The HTTP Warn Code Registry shall be created at
<http://www.iana.org/assignments/http-cache-directives> and be <http://www.iana.org/assignments/http-cache-directives> and be
populated with the registrations below: populated with the registrations below:
+-----------+----------------------------------+---------------+ +-----------+----------------------------------+---------------+
| Warn Code | Short Description | Reference | | Warn Code | Short Description | Reference |
+-----------+----------------------------------+---------------+ +-----------+----------------------------------+---------------+
| 110 | Response is Stale | Section 3.6.1 | | 110 | Response is Stale | Section 3.6.1 |
| 111 | Revalidation Failed | Section 3.6.2 | | 111 | Revalidation Failed | Section 3.6.2 |
| 112 | Disconnected Operation | Section 3.6.3 | | 112 | Disconnected Operation | Section 3.6.3 |
| 113 | Heuristic Expiration | Section 3.6.4 | | 113 | Heuristic Expiration | Section 3.6.4 |
| 199 | Miscellaneous Warning | Section 3.6.5 | | 199 | Miscellaneous Warning | Section 3.6.5 |
| 214 | Transformation Applied | Section 3.6.6 | | 214 | Transformation Applied | Section 3.6.6 |
| 299 | Miscellaneous Persistent Warning | Section 3.6.7 | | 299 | Miscellaneous Persistent Warning | Section 3.6.7 |
+-----------+----------------------------------+---------------+ +-----------+----------------------------------+---------------+
3.9. Header Field Registration 5.3. Header Field Registration
The Message Header Field Registry located at <http://www.iana.org/ The Message Header Field Registry located at <http://www.iana.org/
assignments/message-headers/message-header-index.html> shall be assignments/message-headers/message-header-index.html> shall be
updated with the permanent registrations below (see [RFC3864]): updated with the permanent registrations below (see [RFC3864]):
+-------------------+----------+----------+-------------+ +-------------------+----------+----------+-------------+
| Header Field Name | Protocol | Status | Reference | | Header Field Name | Protocol | Status | Reference |
+-------------------+----------+----------+-------------+ +-------------------+----------+----------+-------------+
| Age | http | standard | Section 3.1 | | Age | http | standard | Section 3.1 |
| Cache-Control | http | standard | Section 3.2 | | Cache-Control | http | standard | Section 3.2 |
| Expires | http | standard | Section 3.3 | | Expires | http | standard | Section 3.3 |
| Pragma | http | standard | Section 3.4 | | Pragma | http | standard | Section 3.4 |
| Vary | http | standard | Section 3.5 | | Vary | http | standard | Section 3.5 |
| Warning | http | standard | Section 3.6 | | Warning | http | standard | Section 3.6 |
+-------------------+----------+----------+-------------+ +-------------------+----------+----------+-------------+
The change controller is: "IETF (iesg@ietf.org) - Internet The change controller is: "IETF (iesg@ietf.org) - Internet
Engineering Task Force". Engineering Task Force".
4. Security Considerations 6. Security Considerations
Caches expose additional potential vulnerabilities, since the Caches expose additional potential vulnerabilities, since the
contents of the cache represent an attractive target for malicious contents of the cache represent an attractive target for malicious
exploitation. Because cache contents persist after an HTTP request exploitation. Because cache contents persist after an HTTP request
is complete, an attack on the cache can reveal information long after is complete, an attack on the cache can reveal information long after
a user believes that the information has been removed from the a user believes that the information has been removed from the
network. Therefore, cache contents need to be protected as sensitive network. Therefore, cache contents need to be protected as sensitive
information. information.
5. Acknowledgments 7. Acknowledgments
See Section 11 of [Part1].
6. References See Section 9 of [Part1].
6.1. Normative References 8. References
8.1. Normative References
[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part1] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., "HTTP/1.1, part 1: URIs, Connections, and Message
and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, Parsing", draft-ietf-httpbis-p1-messaging-19 (work in
and Message Parsing", draft-ietf-httpbis-p1-messaging-18 progress), March 2012.
(work in progress), January 2012.
[Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part2] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., "HTTP/1.1, part 2: Message Semantics",
and J. Reschke, Ed., "HTTP/1.1, part 2: Message draft-ietf-httpbis-p2-semantics-19 (work in progress),
Semantics", draft-ietf-httpbis-p2-semantics-18 (work in March 2012.
progress), January 2012.
[Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part4] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., "HTTP/1.1, part 4: Conditional Requests",
and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional draft-ietf-httpbis-p4-conditional-19 (work in progress),
Requests", draft-ietf-httpbis-p4-conditional-18 (work in March 2012.
progress), January 2012.
[Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., "HTTP/1.1, part 5: Range Requests and Partial Responses",
and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and draft-ietf-httpbis-p5-range-19 (work in progress),
Partial Responses", draft-ietf-httpbis-p5-range-18 (work March 2012.
in progress), January 2012.
[Part7] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part7] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., "HTTP/1.1, part 7: Authentication",
and J. Reschke, Ed., "HTTP/1.1, part 7: Authentication", draft-ietf-httpbis-p7-auth-19 (work in progress),
draft-ietf-httpbis-p7-auth-18 (work in progress), March 2012.
January 2012.
[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.
6.2. Informative References 8.2. Informative References
[RFC1305] Mills, D., "Network Time Protocol (Version 3) [RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation", RFC 1305, March 1992. Specification, Implementation", RFC 1305, March 1992.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864, Procedures for Message Header Fields", BCP 90, RFC 3864,
skipping to change at page 36, line 4 skipping to change at page 36, line 17
Content", RFC 5861, April 2010. Content", RFC 5861, April 2010.
Appendix A. Changes from RFC 2616 Appendix A. Changes from RFC 2616
Make the specified age calculation algorithm less conservative. Make the specified age calculation algorithm less conservative.
(Section 2.3.2) (Section 2.3.2)
Remove requirement to consider Content-Location in successful Remove requirement to consider Content-Location in successful
responses in order to determine the appropriate response to use. responses in order to determine the appropriate response to use.
(Section 2.4) (Section 2.4)
Clarify denial of service attack avoidance requirement. Clarify denial of service attack avoidance requirement.
(Section 2.5) (Section 2.6)
Change ABNF productions for header fields to only define the field Change ABNF productions for header fields to only define the field
value. (Section 3) value. (Section 3)
Do not mention RFC 2047 encoding and multiple languages in Warning Do not mention RFC 2047 encoding and multiple languages in Warning
header fields anymore, as these aspects never were implemented. header fields anymore, as these aspects never were implemented.
(Section 3.6) (Section 3.6)
Appendix B. Collected ABNF Appendix B. Collected ABNF
Age = delta-seconds Age = delta-seconds
Cache-Control = *( "," OWS ) cache-directive *( OWS "," [ OWS Cache-Control = *( "," OWS ) cache-directive *( OWS "," [ OWS
cache-directive ] ) cache-directive ] )
Expires = HTTP-date Expires = HTTP-date
HTTP-date = <HTTP-date, defined in [Part2], Section 8> HTTP-date = <HTTP-date, defined in [Part2], Section 8>
OWS = <OWS, defined in [Part1], Section 1.2.2> OWS = <OWS, defined in [Part1], Section 3.2.1>
Pragma = *( "," OWS ) pragma-directive *( OWS "," [ OWS Pragma = *( "," OWS ) pragma-directive *( OWS "," [ OWS
pragma-directive ] ) pragma-directive ] )
Vary = "*" / ( *( "," OWS ) field-name *( OWS "," [ OWS field-name ] Vary = "*" / ( *( "," OWS ) field-name *( OWS "," [ OWS field-name ]
) ) ) )
Warning = *( "," OWS ) warning-value *( OWS "," [ OWS warning-value ] Warning = *( "," OWS ) warning-value *( OWS "," [ OWS warning-value ]
) )
skipping to change at page 37, line 4 skipping to change at page 37, line 18
cache-response-directive = "public" / ( "private" [ "=" DQUOTE *( "," cache-response-directive = "public" / ( "private" [ "=" DQUOTE *( ","
OWS ) field-name *( OWS "," [ OWS field-name ] ) DQUOTE ] ) / ( OWS ) field-name *( OWS "," [ OWS field-name ] ) DQUOTE ] ) / (
"no-cache" [ "=" DQUOTE *( "," OWS ) field-name *( OWS "," [ OWS "no-cache" [ "=" DQUOTE *( "," OWS ) field-name *( OWS "," [ OWS
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.7> 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 8.8> pseudonym = <pseudonym, defined in [Part1], Section 6.2>
quoted-string = <quoted-string, defined in [Part1], Section 3.2.3> quoted-string = <quoted-string, defined in [Part1], Section 3.2.4>
token = <token, defined in [Part1], Section 3.2.3> token = <token, defined in [Part1], Section 3.2.4>
uri-host = <uri-host, defined in [Part1], Section 2.7> 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
] ]
skipping to change at page 43, line 28 skipping to change at page 43, line 40
o <http://tools.ietf.org/wg/httpbis/trac/ticket/293>: "Interaction o <http://tools.ietf.org/wg/httpbis/trac/ticket/293>: "Interaction
of request and response Cache-Control" of request and response Cache-Control"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/212>: "Refining age o <http://tools.ietf.org/wg/httpbis/trac/ticket/212>: "Refining age
for 1.1 proxy chains" for 1.1 proxy chains"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/274>: "warn-code o <http://tools.ietf.org/wg/httpbis/trac/ticket/274>: "warn-code
registry" registry"
C.20. Since draft-ietf-httpbis-p6-cache-18
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/227>: "Combining
HEAD responses"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/337>: "Field names
in cache-control header arguments"
Index Index
1 1
110 Response is Stale (warn code) 31 110 Response is Stale (warn code) 31
111 Revalidation Failed (warn code) 31 111 Revalidation Failed (warn code) 31
112 Disconnected Operation (warn code) 31 112 Disconnected Operation (warn code) 31
113 Heuristic Expiration (warn code) 31 113 Heuristic Expiration (warn code) 32
199 Miscellaneous Warning (warn code) 31 199 Miscellaneous Warning (warn code) 32
2 2
214 Transformation Applied (warn code) 31 214 Transformation Applied (warn code) 32
299 Miscellaneous Persistent Warning (warn code) 31 299 Miscellaneous Persistent Warning (warn code) 32
A A
age 6 age 6
Age header field 20 Age header field 21
C C
cache 5 cache 5
Cache Directives Cache Directives
max-age 22, 25 max-age 23, 26
max-stale 22 max-stale 23
min-fresh 22 min-fresh 23
must-revalidate 25 must-revalidate 25
no-cache 22, 24 no-cache 22, 24
no-store 22, 24 no-store 22, 25
no-transform 23, 25 no-transform 23, 26
only-if-cached 23 only-if-cached 23
private 23 private 24
proxy-revalidate 25 proxy-revalidate 26
public 23 public 24
s-maxage 25 s-maxage 26
cache entry 8 cache entry 8
cache key 8 cache key 8
Cache-Control header field 21 Cache-Control header field 21
cacheable 5 cacheable 5
E E
Expires header field 27 Expires header field 27
explicit expiration time 6 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 20 Age 21
Cache-Control 21 Cache-Control 22
cache-extension 21 cache-extension 22
cache-request-directive 21 cache-request-directive 22
cache-response-directive 23 cache-response-directive 24
delta-seconds 8 delta-seconds 8
Expires 27 Expires 28
extension-pragma 28 extension-pragma 28
Pragma 28 Pragma 28
pragma-directive 28 pragma-directive 28
Vary 29 Vary 29
warn-agent 30 warn-agent 30
warn-code 30 warn-code 30
warn-date 30 warn-date 30
warn-text 30 warn-text 30
Warning 30 Warning 30
warning-value 30 warning-value 30
H H
Header Fields Header Fields
Age 20 Age 21
Cache-Control 21 Cache-Control 21
Expires 27 Expires 27
Pragma 28 Pragma 28
Vary 28 Vary 29
Warning 29 Warning 30
heuristic expiration time 6 heuristic expiration time 6
M M
max-age max-age
Cache Directive 22, 25 Cache Directive 23, 26
max-stale max-stale
Cache Directive 22 Cache Directive 23
min-fresh min-fresh
Cache Directive 22 Cache Directive 23
must-revalidate must-revalidate
Cache Directive 25 Cache Directive 25
N N
no-cache no-cache
Cache Directive 22, 24 Cache Directive 22, 24
no-store no-store
Cache Directive 22, 24 Cache Directive 22, 25
no-transform no-transform
Cache Directive 23, 25 Cache Directive 23, 26
O O
only-if-cached only-if-cached
Cache Directive 23 Cache Directive 23
P P
Pragma header field 28 Pragma header field 28
private private
Cache Directive 23 Cache Directive 24
private cache 5 private cache 5
proxy-revalidate proxy-revalidate
Cache Directive 25 Cache Directive 26
public public
Cache Directive 23 Cache Directive 24
S S
s-maxage s-maxage
Cache Directive 25 Cache Directive 26
shared cache 5 shared cache 5
stale 6 stale 6
strong validator 7 strong validator 7
V V
validator 6 validator 6
strong 7 strong 7
Vary header field 28 Vary header field 29
W W
Warn Codes Warn Codes
110 Response is Stale 31 110 Response is Stale 31
111 Revalidation Failed 31 111 Revalidation Failed 31
112 Disconnected Operation 31 112 Disconnected Operation 31
113 Heuristic Expiration 31 113 Heuristic Expiration 32
199 Miscellaneous Warning 31 199 Miscellaneous Warning 32
214 Transformation Applied 31 214 Transformation Applied 32
299 Miscellaneous Persistent Warning 31 299 Miscellaneous Persistent Warning 32
Warning header field 29 Warning header field 30
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
URI: http://roy.gbiv.com/ URI: http://roy.gbiv.com/
Jim Gettys
Alcatel-Lucent Bell Labs
21 Oak Knoll Road
Carlisle, MA 01741
USA
EMail: jg@freedesktop.org
URI: http://gettys.wordpress.com/
Jeffrey C. Mogul
Hewlett-Packard Company
HP Labs, Large Scale Systems Group
1501 Page Mill Road, MS 1177
Palo Alto, CA 94304
USA
EMail: JeffMogul@acm.org
Henrik Frystyk Nielsen
Microsoft Corporation
1 Microsoft Way
Redmond, WA 98052
USA
EMail: henrikn@microsoft.com
Larry Masinter
Adobe Systems Incorporated
345 Park Ave
San Jose, CA 95110
USA
EMail: LMM@acm.org
URI: http://larry.masinter.net/
Paul J. Leach
Microsoft Corporation
1 Microsoft Way
Redmond, WA 98052
EMail: paulle@microsoft.com
Tim Berners-Lee
World Wide Web Consortium
MIT Computer Science and Artificial Intelligence Laboratory
The Stata Center, Building 32
32 Vassar Street
Cambridge, MA 02139
USA
EMail: timbl@w3.org
URI: http://www.w3.org/People/Berners-Lee/
Yves Lafon (editor) Yves Lafon (editor)
World Wide Web Consortium World Wide Web Consortium
W3C / ERCIM W3C / ERCIM
2004, rte des Lucioles 2004, rte des Lucioles
Sophia-Antipolis, AM 06902 Sophia-Antipolis, AM 06902
France France
EMail: ylafon@w3.org EMail: ylafon@w3.org
URI: http://www.raubacapeu.net/people/yves/ URI: http://www.raubacapeu.net/people/yves/
 End of changes. 92 change blocks. 
230 lines changed or deleted 204 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/