draft-ietf-httpbis-p6-cache-25.txt   draft-ietf-httpbis-p6-cache-26.txt 
HTTPbis Working Group R. Fielding, Ed. HTTPbis Working Group R. Fielding, Ed.
Internet-Draft Adobe Internet-Draft Adobe
Obsoletes: 2616 (if approved) M. Nottingham, Ed. Obsoletes: 2616 (if approved) M. Nottingham, Ed.
Intended status: Standards Track Akamai Intended status: Standards Track Akamai
Expires: May 21, 2014 J. Reschke, Ed. Expires: August 10, 2014 J. Reschke, Ed.
greenbytes greenbytes
November 17, 2013 February 6, 2014
Hypertext Transfer Protocol (HTTP/1.1): Caching Hypertext Transfer Protocol (HTTP/1.1): Caching
draft-ietf-httpbis-p6-cache-25 draft-ietf-httpbis-p6-cache-26
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is an application-level The Hypertext Transfer Protocol (HTTP) is a stateless application-
protocol for distributed, collaborative, hypertext information level protocol for distributed, collaborative, hypertext information
systems. This document defines requirements on HTTP caches and the systems. This document defines HTTP caches and the associated header
associated header fields that control cache behavior or indicate fields that control cache behavior or indicate cacheable response
cacheable response messages. messages.
Editorial Note (To be removed by RFC Editor) Editorial Note (To be removed by RFC Editor)
Discussion of this draft takes place on the HTTPBIS working group Discussion of this draft takes place on the HTTPBIS working group
mailing list (ietf-http-wg@w3.org), which is archived at 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 D.1. The changes in this draft are summarized in Appendix D.2.
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 May 21, 2014. This Internet-Draft will expire on August 10, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 19 skipping to change at page 3, line 19
4.4. Invalidation . . . . . . . . . . . . . . . . . . . . . . . 19 4.4. Invalidation . . . . . . . . . . . . . . . . . . . . . . . 19
5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 20 5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 20
5.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 5.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 21 5.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 21
5.2.1. Request Cache-Control Directives . . . . . . . . . . . 21 5.2.1. Request Cache-Control Directives . . . . . . . . . . . 21
5.2.2. Response Cache-Control Directives . . . . . . . . . . 23 5.2.2. Response Cache-Control Directives . . . . . . . . . . 23
5.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 26 5.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 26
5.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 28 5.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.5. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 29 5.5. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.5.1. Warning: 110 - "Response is Stale" . . . . . . . . . . 31 5.5.1. Warning: 110 - "Response is Stale" . . . . . . . . . . 30
5.5.2. Warning: 111 - "Revalidation Failed" . . . . . . . . . 31 5.5.2. Warning: 111 - "Revalidation Failed" . . . . . . . . . 31
5.5.3. Warning: 112 - "Disconnected Operation" . . . . . . . 31 5.5.3. Warning: 112 - "Disconnected Operation" . . . . . . . 31
5.5.4. Warning: 113 - "Heuristic Expiration" . . . . . . . . 31 5.5.4. Warning: 113 - "Heuristic Expiration" . . . . . . . . 31
5.5.5. Warning: 199 - "Miscellaneous Warning" . . . . . . . . 31 5.5.5. Warning: 199 - "Miscellaneous Warning" . . . . . . . . 31
5.5.6. Warning: 214 - "Transformation Applied" . . . . . . . 31 5.5.6. Warning: 214 - "Transformation Applied" . . . . . . . 31
5.5.7. Warning: 299 - "Miscellaneous Persistent Warning" . . 31 5.5.7. Warning: 299 - "Miscellaneous Persistent Warning" . . 31
6. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 31 6. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 31
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
7.1. Cache Directive Registry . . . . . . . . . . . . . . . . . 32 7.1. Cache Directive Registry . . . . . . . . . . . . . . . . . 32
7.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 32 7.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 32
7.1.2. Considerations for New Cache Control Directives . . . 32 7.1.2. Considerations for New Cache Control Directives . . . 32
7.1.3. Registrations . . . . . . . . . . . . . . . . . . . . 33 7.1.3. Registrations . . . . . . . . . . . . . . . . . . . . 32
7.2. Warn Code Registry . . . . . . . . . . . . . . . . . . . . 33 7.2. Warn Code Registry . . . . . . . . . . . . . . . . . . . . 33
7.2.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 33 7.2.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 33
7.2.2. Registrations . . . . . . . . . . . . . . . . . . . . 33 7.2.2. Registrations . . . . . . . . . . . . . . . . . . . . 33
7.3. Header Field Registration . . . . . . . . . . . . . . . . 34 7.3. Header Field Registration . . . . . . . . . . . . . . . . 34
8. Security Considerations . . . . . . . . . . . . . . . . . . . 34 8. Security Considerations . . . . . . . . . . . . . . . . . . . 34
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
10.1. Normative References . . . . . . . . . . . . . . . . . . . 35 10.1. Normative References . . . . . . . . . . . . . . . . . . . 35
10.2. Informative References . . . . . . . . . . . . . . . . . . 36 10.2. Informative References . . . . . . . . . . . . . . . . . . 36
Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 36 Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 36
Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 38 Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 38
Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 38 Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 38
Appendix D. Change Log (to be removed by RFC Editor before Appendix D. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 39 publication) . . . . . . . . . . . . . . . . . . . . 39
D.1. Since draft-ietf-httpbis-p6-cache-24 . . . . . . . . . . . 40 D.1. Since draft-ietf-httpbis-p6-cache-24 . . . . . . . . . . . 40
D.2. Since draft-ietf-httpbis-p6-cache-25 . . . . . . . . . . . 40
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
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.
An HTTP cache is a local store of response messages and the subsystem An HTTP cache is a local store of response messages and the subsystem
that controls storage, retrieval, and deletion of messages in it. A that controls storage, retrieval, and deletion of messages in it. A
cache stores cacheable responses in order to reduce the response time cache stores cacheable responses in order to reduce the response time
and network bandwidth consumption on future, equivalent requests. and network bandwidth consumption on future, equivalent requests.
Any client or server MAY employ a cache, though a cache cannot be Any client or server MAY employ a cache, though a cache cannot be
used by a server that is acting as a tunnel. used by a server that is acting as a tunnel.
A shared cache is a cache that stores responses to be reused by more A shared cache is a cache that stores responses to be reused by more
than one user; shared caches are usually (but not always) deployed as than one user; shared caches are usually (but not always) deployed as
a part of an intermediary. A private cache, in contrast, is a part of an intermediary. A private cache, in contrast, is
dedicated to a single user. dedicated to a single user; often, they are deployed as a component
of a user agent.
The goal of caching in HTTP/1.1 is to significantly improve The goal of caching in HTTP/1.1 is to significantly improve
performance by reusing a prior response message to satisfy a current performance by reusing a prior response message to satisfy a current
request. A stored response is considered "fresh", as defined in request. A stored response is considered "fresh", as defined in
Section 4.2, if the response can be reused without "validation" Section 4.2, if the response can be reused without "validation"
(checking with the origin server to see if the cached response (checking with the origin server to see if the cached response
remains valid for this request). A fresh response can therefore remains valid for this request). A fresh response can therefore
reduce both latency and network overhead each time it is reused. reduce both latency and network overhead each time it is reused.
When a cached response is not fresh, it might still be reusable if it When a cached response is not fresh, it might still be reusable if it
can be freshened by validation (Section 4.3) or if the origin is can be freshened by validation (Section 4.3) or if the origin is
skipping to change at page 4, line 47 skipping to change at page 4, line 48
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Conformance criteria and considerations regarding error handling are Conformance criteria and considerations regarding error handling are
defined in Section 2.5 of [Part1]. defined in Section 2.5 of [Part1].
1.2. Syntax Notation 1.2. Syntax Notation
This specification uses the Augmented Backus-Naur Form (ABNF) This specification uses the Augmented Backus-Naur Form (ABNF)
notation of [RFC5234] with the list rule extension defined in Section notation of [RFC5234] with a list extension, defined in Section 7 of
7 of [Part1]. Appendix B describes rules imported from other [Part1], that allows for compact definition of comma-separated lists
documents. Appendix C shows the collected ABNF with the list rule using a '#' operator (similar to how the '*' operator indicates
expanded. repetition). Appendix B describes rules imported from other
documents. Appendix C shows the collected grammar with all list
operators expanded to standard ABNF notation.
1.2.1. Delta Seconds 1.2.1. 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
A recipient parsing a delta-seconds value and converting it to binary A recipient parsing a delta-seconds value and converting it to binary
form ought to use an arithmetic type of at least 31 bits of non- form ought to use an arithmetic type of at least 31 bits of non-
skipping to change at page 5, line 34 skipping to change at page 5, line 35
are performed with an arithmetic type incapable of directly are performed with an arithmetic type incapable of directly
representing that number. What matters here is that an overflow representing that number. What matters here is that an overflow
be detected and not treated as a negative value in later be detected and not treated as a negative value in later
calculations. calculations.
2. Overview of Cache Operation 2. Overview of Cache Operation
Proper cache operation preserves the semantics of HTTP transfers Proper cache operation preserves the semantics of HTTP transfers
([Part2]) while eliminating the transfer of information already held ([Part2]) while eliminating the transfer of information already held
in the cache. Although caching is an entirely OPTIONAL feature of in the cache. Although caching is an entirely OPTIONAL feature of
HTTP, we assume that reusing the cached response is desirable and HTTP, it can be assumed that reusing a cached response is desirable
that such reuse is the default behavior when no requirement or local and that such reuse is the default behavior when no requirement or
configuration prevents it. Therefore, HTTP cache requirements are local configuration prevents it. Therefore, HTTP cache requirements
focused on preventing a cache from either storing a non-reusable are focused on preventing a cache from either storing a non-reusable
response or reusing a stored response inappropriately, rather than response or reusing a stored response inappropriately, rather than
mandating that caches always store and reuse particular responses. mandating that caches always store and reuse particular responses.
Each cache entry consists of a cache key and one or more HTTP Each cache entry consists of a cache key and one or more HTTP
responses corresponding to prior requests that used the same key. responses corresponding to prior requests that used the same key.
The most common form of cache entry is a successful result of a The most common form of cache entry is a successful result of a
retrieval request: i.e., a 200 (OK) response to a GET request, which retrieval request: i.e., a 200 (OK) response to a GET request, which
contains a representation of the resource identified by the request contains a representation of the resource identified by the request
target (Section 4.3.1 of [Part2]). However, it is also possible to target (Section 4.3.1 of [Part2]). However, it is also possible to
cache permanent redirects, negative results (e.g., 404 (Not Found)), cache permanent redirects, negative results (e.g., 404 (Not Found)),
skipping to change at page 6, line 26 skipping to change at page 6, line 27
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 5.2) does not appear o the "no-store" cache directive (see Section 5.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 5.2.2.6) does o the "private" response directive (see Section 5.2.2.6) does not
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 field (see Section 4.1 of [Part7]) does o the Authorization header field (see Section 4.2 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 3.2), and response explicitly allows it (see Section 3.2), and
o the response either: o the response either:
* contains an Expires header field (see Section 5.3), or * contains an Expires header field (see Section 5.3), or
* contains a max-age response cache directive (see * contains a max-age response directive (see Section 5.2.2.8), or
Section 5.2.2.8), or
* contains a s-maxage response cache directive (see * contains a s-maxage response directive (see Section 5.2.2.9)
Section 5.2.2.9) and the cache is shared, or and the cache is shared, or
* contains a Cache Control Extension (see Section 5.2.3) that * contains a Cache Control Extension (see Section 5.2.3) that
allows it to be cached, or allows it to be cached, or
* has a status code that is defined as cacheable by default (see * has a status code that is defined as cacheable by default (see
Section 4.2.2), or Section 4.2.2), or
* contains a public response cache directive (see * contains a public response directive (see Section 5.2.2.5).
Section 5.2.2.5).
Note that any of the requirements listed above can be overridden by a Note that any of the requirements listed above can be overridden by a
cache-control extension; see Section 5.2.3. cache-control extension; see Section 5.2.3.
In this context, a cache has "understood" a request method or a In this context, a cache has "understood" a request method or a
response status code if it recognizes it and implements all specified response status code if it recognizes it and implements all specified
caching-related behavior. caching-related behavior.
Note that, in normal operation, some caches will not store a response Note that, in normal operation, some 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,
skipping to change at page 7, line 41 skipping to change at page 7, line 40
response with the stored entry, as defined in Section 3.3. A cache response with the stored entry, as defined in Section 3.3. 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.
3.2. Storing Responses to Authenticated Requests 3.2. Storing Responses to Authenticated Requests
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.2 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 5.2.2) have such an effect: must-revalidate, directives (Section 5.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 4.2.4) by shared caches. In particular, a response with (Section 4.2.4) by shared caches. In particular, a response with
skipping to change at page 11, line 12 skipping to change at page 11, line 8
A response's age is the time that has passed since it was generated A response's age is the time that has passed since it was generated
by, or successfully validated with, the origin server. by, or successfully validated with, the origin server.
When a response is "fresh" in the cache, it can be used to satisfy When a response is "fresh" in the cache, it can be used to satisfy
subsequent requests without contacting the origin server, thereby subsequent requests without contacting the origin server, thereby
improving efficiency. improving efficiency.
The primary mechanism for determining freshness is for an origin The primary mechanism for determining freshness is for an origin
server to provide an explicit expiration time in the future, using server to provide an explicit expiration time in the future, using
either the Expires header field (Section 5.3) or the max-age response either the Expires header field (Section 5.3) or the max-age response
cache directive (Section 5.2.2.8). Generally, origin servers will directive (Section 5.2.2.8). Generally, origin servers will assign
assign future explicit expiration times to responses in the belief future explicit expiration times to responses in the belief that the
that the representation is not likely to change in a semantically representation is not likely to change in a semantically significant
significant way before the expiration time is reached. way before the expiration time is reached.
If an origin server wishes to force a cache to validate every If an origin server wishes to force a cache to validate every
request, it can assign an explicit expiration time in the past to request, it can assign an explicit expiration time in the past to
indicate that the response is already stale. Compliant caches will indicate that the response is already stale. Compliant caches will
normally validate a stale cached response before reusing it for normally validate a stale cached response before reusing it for
subsequent requests (see Section 4.2.4). subsequent requests (see Section 4.2.4).
Since origin servers do not always provide explicit expiration times, Since origin servers do not always provide explicit expiration times,
caches are also allowed to use a heuristic to determine an expiration caches are also allowed to use a heuristic to determine an expiration
time under certain circumstances (see Section 4.2.2). time under certain circumstances (see Section 4.2.2).
skipping to change at page 12, line 18 skipping to change at page 12, line 12
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 6 for an explanation of the difference between resource. See Section 6 for an explanation of the difference between
caches and history mechanisms. caches and history mechanisms.
4.2.1. Calculating Freshness Lifetime 4.2.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 directive
(Section 5.2.2.9) is present, use its value, or (Section 5.2.2.9) is present, use its value, or
o If the max-age response cache directive (Section 5.2.2.8) is o If the max-age response directive (Section 5.2.2.8) is present,
present, use its value, or use its value, or
o If the Expires response header field (Section 5.3) is present, use o If the Expires response header field (Section 5.3) is present, use
its value minus the value of the Date response header field, or its value minus the value of the Date response header field, or
o Otherwise, no explicit expiration time is present in the response. o Otherwise, no explicit expiration time is present in the response.
A heuristic freshness lifetime might be applicable; see A heuristic freshness lifetime might be applicable; see
Section 4.2.2. Section 4.2.2.
Note that this calculation is not vulnerable to clock skew, since all Note that this calculation is not vulnerable to clock skew, since all
of the information comes from the origin server. of the information comes from the origin server.
skipping to change at page 13, line 7 skipping to change at page 12, line 50
expiration time. This specification does not provide specific expiration time. This specification does not provide specific
algorithms, but does impose worst-case constraints on their results. algorithms, but does impose worst-case constraints on their results.
A cache MUST NOT use heuristics to determine freshness when an A cache MUST NOT use heuristics to determine freshness when an
explicit expiration time is present in the stored response. Because explicit expiration time is present in the stored response. Because
of the requirements in Section 3, this means that, effectively, of the requirements in Section 3, this means that, effectively,
heuristics can only be used on responses without explicit freshness heuristics can only be used on responses without explicit freshness
whose status codes are defined as cacheable by default (see Section whose status codes are defined as cacheable by default (see Section
6.1 of [Part2]), and those responses without explicit freshness that 6.1 of [Part2]), and those responses without explicit freshness that
have been marked as explicitly cacheable (e.g., with a "public" have been marked as explicitly cacheable (e.g., with a "public"
response cache directive). response directive).
If the response has a Last-Modified header field (Section 2.2 of If the response has a Last-Modified header field (Section 2.2 of
[Part4]), caches are encouraged to use a heuristic expiration value [Part4]), caches are encouraged to use a heuristic expiration value
that is no more than some fraction of the interval since that time. that is no more than some fraction of the interval since that time.
A typical setting of this fraction might be 10%. A typical setting of this fraction might be 10%.
When a heuristic is used to calculate freshness lifetime, a cache When a heuristic is used to calculate freshness lifetime, a cache
SHOULD generate a Warning header field with a 113 warn-code (see SHOULD generate a Warning header field with a 113 warn-code (see
Section 5.5.4) in the response if its current_age is more than 24 Section 5.5.4) in the response if its current_age is more than 24
hours and such a warning is not already present. hours and such a warning is not already present.
skipping to change at page 19, line 25 skipping to change at page 19, line 25
When a cache makes an inbound HEAD request for a given request target When a cache makes an inbound HEAD request for a given request target
and receives a 200 (OK) response, the cache SHOULD update or and receives a 200 (OK) response, the cache SHOULD update or
invalidate each of its stored GET responses that could have been invalidate each of its stored GET responses that could have been
selected for that request (see Section 4.1). selected for that request (see Section 4.1).
For each of the stored responses that could have been selected, if For each of the stored responses that could have been selected, if
the stored response and HEAD response have matching values for any the stored response and HEAD response have matching values for any
received validator fields (ETag and Last-Modified) and, if the HEAD received validator fields (ETag and Last-Modified) and, if the HEAD
response has a Content-Length header field, the value of Content- response has a Content-Length header field, the value of Content-
Length matches that of the stored response, the cache SHOULD update Length matches that of the stored response, the cache SHOULD update
the stored response a described below; otherwise, the cache SHOULD the stored response as described below; otherwise, the cache SHOULD
consider the stored response to be stale. consider the stored response to be stale.
If a cache updates a stored response with the metadata provided in a If a cache updates a stored response with the metadata provided in a
HEAD response, the cache MUST: HEAD response, the 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 5.5); code 1xx (see Section 5.5);
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 26, line 45 skipping to change at page 26, line 45
field. The s-maxage directive also implies the semantics of the field. The s-maxage directive also implies the semantics of the
proxy-revalidate response directive. proxy-revalidate response directive.
This directive uses the token form of the argument syntax; e.g., This directive uses the token form of the argument syntax; e.g.,
's-maxage=10', not 's-maxage="10"'. A sender SHOULD NOT generate the 's-maxage=10', not 's-maxage="10"'. A sender SHOULD NOT generate the
quoted-string form. quoted-string form.
5.2.3. Cache Control Extensions 5.2.3. Cache Control Extensions
The Cache-Control header field can be extended through the use of one The Cache-Control header field can be extended through the use of one
or more cache-extension tokens, each with an optional value. or more cache-extension tokens, each with an optional value. A cache
MUST ignore unrecognized cache directives.
Informational extensions (those that do not require a change in cache Informational extensions (those that do not require a change in cache
behavior) can be added without changing the semantics of other behavior) can be added without changing the semantics of other
directives. Behavioral extensions are designed to work by acting as directives.
modifiers to the existing base of cache directives.
Both the new directive and the standard directive are supplied, such
that applications that do not understand the new directive will
default to the behavior specified by the standard directive, and
those that understand the new directive will recognize it as
modifying the requirements associated with the standard directive.
In this way, extensions to the cache-control directives can be made
without requiring changes to the base protocol.
This extension mechanism depends on an HTTP cache obeying all of the Behavioral extensions are designed to work by acting as modifiers to
cache-control directives defined for its native HTTP-version, obeying the existing base of cache directives. Both the new directive and
certain extensions, and ignoring all directives that it does not the old directive are supplied, such that applications that do not
understand. understand the new directive will default to the behavior specified
by the old directive, and those that understand the new directive
will recognize it as modifying the requirements associated with the
old directive. In this way, extensions to the existing cache-control
directives can be made without breaking deployed caches.
For example, consider a hypothetical new response directive called For example, consider a hypothetical new response directive called
"community" that acts as a modifier to the private directive. We "community" that acts as a modifier to the private directive: in
define this new directive to mean that, in addition to any private addition to private caches, any cache that is shared only by members
cache, any cache that is shared only by members of the community of the named community is allowed to cache the response. An origin
named within its value is allowed to cache the response. An origin
server wishing to allow the UCI community to use an otherwise private server wishing to allow the UCI community to use an otherwise private
response in their shared cache(s) could do so by including response in their shared cache(s) could do so by including
Cache-Control: private, community="UCI" Cache-Control: private, community="UCI"
A cache seeing this header field will act correctly even if the cache A cache that recognizes such a community cache-extension could
does not understand the community cache-extension, since it will also broaden its behavior in accordance with that extension. A cache that
see and understand the private directive and thus default to the safe does not recognize the community cache-extension would ignore it and
behavior. adhere to the private directive.
A cache MUST ignore unrecognized cache directives; it is assumed that
any cache directive likely to be unrecognized by an HTTP/1.1 cache
will be combined with standard directives (or the response's default
cacheability) such that the cache behavior will remain minimally
correct even if the cache does not understand the extension(s).
5.3. Expires 5.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 4.2 for further discussion response is considered stale. See Section 4.2 for further discussion
of the freshness model. of the freshness model.
The presence of an Expires field does not imply that the original The presence of an Expires field does not imply that the original
resource will change or cease to exist at, before, or after that resource will change or cease to exist at, before, or after that
time. time.
skipping to change at page 30, line 40 skipping to change at page 30, line 29
If a sender generates one or more 1xx warn-codes in a message to be If a sender generates one or more 1xx warn-codes in a message to be
sent to a recipient known to implement only HTTP/1.0, the sender MUST sent to a recipient known to implement only HTTP/1.0, the sender MUST
include in each corresponding warning-value a warn-date that matches include in each corresponding warning-value a warn-date that matches
the Date header field in the message. For example: the Date header field in the message. For example:
HTTP/1.1 200 OK HTTP/1.1 200 OK
Date: Sat, 25 Aug 2012 23:34:45 GMT Date: Sat, 25 Aug 2012 23:34:45 GMT
Warning: 112 - "network down" "Sat, 25 Aug 2012 23:34:45 GMT" Warning: 112 - "network down" "Sat, 25 Aug 2012 23:34:45 GMT"
Warnings have accompanying warn-text that describes the error, e.g.,
for logging. It is advisory only, and its content does not affect
interpretation of the warn-code.
If a recipient that uses, evaluates, or displays Warning header If a recipient that uses, evaluates, or displays Warning header
fields receives a warn-date that is different from the Date value in fields receives a warn-date that is different from the Date value in
the same message, the recipient MUST exclude the warning-value the same message, the recipient MUST exclude the warning-value
containing that warn-date before storing, forwarding, or using the containing that warn-date before storing, forwarding, or using the
message. This allows recipients to exclude warning-values that were message. This allows recipients to exclude warning-values that were
improperly retained after a cache validation. If all of the warning- improperly retained after a cache validation. If all of the warning-
values are excluded, the recipient MUST exclude the Warning header values are excluded, the recipient MUST exclude the Warning header
field as well. field as well.
The following warn-codes are defined by this specification, each with The following warn-codes are defined by this specification, each with
skipping to change at page 34, line 43 skipping to change at page 34, line 43
| Pragma | http | standard | Section 5.4 | | Pragma | http | standard | Section 5.4 |
| Warning | http | standard | Section 5.5 | | Warning | http | standard | Section 5.5 |
+-------------------+----------+----------+-------------+ +-------------------+----------+----------+-------------+
The change controller is: "IETF (iesg@ietf.org) - Internet The change controller is: "IETF (iesg@ietf.org) - Internet
Engineering Task Force". Engineering Task Force".
8. Security Considerations 8. Security Considerations
This section is meant to inform developers, information providers, This section is meant to inform developers, information providers,
and users of known security concerns specific to HTTP/1.1 caching. and users of known security concerns specific to HTTP caching. More
More general security considerations are addressed in HTTP messaging general security considerations are addressed in HTTP messaging
[Part1] and semantics [Part2]. [Part1] and semantics [Part2].
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.
Furthermore, the very use of a cache can bring about privacy In particular, various attacks might be amplified by being stored in
concerns. For example, if two users share a cache, and the first one a shared cache; such "cache poisoning" attacks use the cache to
browses to a site, the second may be able to detect that the other distribute a malicious payload to many clients, and are especially
has been to that site, because the resources from it load more effective when an attacker can use implementation flaws, elevated
quickly, thanks to the cache. privileges, or other techniques to insert such a response into a
cache. One common attack vector for cache poisoning is to exploit
Implementation flaws might allow attackers to insert content into a differences in message parsing on proxies and in user agents; see
cache ("cache poisoning"), leading to compromise of clients that Section 3.3.3 of [Part1] for the relevant requirements.
trust that content. Because of their nature, these attacks are
difficult to mitigate.
Likewise, implementation flaws (as well as misunderstanding of cache Likewise, implementation flaws (as well as misunderstanding of cache
operation) might lead to caching of sensitive information (e.g., operation) might lead to caching of sensitive information (e.g.,
authentication credentials) that is thought to be private, exposing authentication credentials) that is thought to be private, exposing
it to unauthorized parties. it to unauthorized parties.
Furthermore, the very use of a cache can bring about privacy
concerns. For example, if two users share a cache, and the first one
browses to a site, the second may be able to detect that the other
has been to that site, because the resources from it load more
quickly, thanks to the cache.
Note that the Set-Cookie response header field [RFC6265] does not Note that the Set-Cookie response header field [RFC6265] does not
inhibit caching; a cacheable response with a Set-Cookie header field inhibit caching; a cacheable response with a Set-Cookie header field
can be (and often is) used to satisfy subsequent requests to caches. can be (and often is) used to satisfy subsequent requests to caches.
Servers who wish to control caching of these responses are encouraged Servers who wish to control caching of these responses are encouraged
to emit appropriate Cache-Control response header fields. to emit appropriate Cache-Control response header fields.
9. Acknowledgments 9. Acknowledgments
See Section 10 of [Part1]. See Section 10 of [Part1].
10. References 10. References
10.1. Normative References 10.1. Normative References
[Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
draft-ietf-httpbis-p1-messaging-25 (work in progress), draft-ietf-httpbis-p1-messaging-26 (work in progress),
November 2013. February 2014.
[Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", Protocol (HTTP/1.1): Semantics and Content",
draft-ietf-httpbis-p2-semantics-25 (work in progress), draft-ietf-httpbis-p2-semantics-26 (work in progress),
November 2013. February 2014.
[Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Conditional Requests", Protocol (HTTP/1.1): Conditional Requests",
draft-ietf-httpbis-p4-conditional-25 (work in progress), draft-ietf-httpbis-p4-conditional-26 (work in progress),
November 2013. February 2014.
[Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., [Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
"Hypertext Transfer Protocol (HTTP/1.1): Range Requests", "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
draft-ietf-httpbis-p5-range-25 (work in progress), draft-ietf-httpbis-p5-range-26 (work in progress),
November 2013. February 2014.
[Part7] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [Part7] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Authentication", Protocol (HTTP/1.1): Authentication",
draft-ietf-httpbis-p7-auth-25 (work in progress), draft-ietf-httpbis-p7-auth-26 (work in progress),
November 2013. February 2014.
[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.
10.2. Informative References 10.2. Informative References
[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration
skipping to change at page 37, line 30 skipping to change at page 37, line 34
Requirements regarding denial of service attack avoidance when Requirements regarding denial of service attack avoidance when
performing invalidation have been clarified. (Section 4.4) performing invalidation have been clarified. (Section 4.4)
Cache invalidation only occurs when a successful response is Cache invalidation only occurs when a successful response is
received. (Section 4.4) received. (Section 4.4)
Cache directives are explicitly defined to be case-insensitive. Cache directives are explicitly defined to be case-insensitive.
Handling of multiple instances of cache directives when only one is Handling of multiple instances of cache directives when only one is
expected is now defined. (Section 5.2) expected is now defined. (Section 5.2)
The "no-store" cache request directive doesn't apply to responses; The "no-store" request directive doesn't apply to responses; i.e., a
i.e., a cache can satisfy a request with no-store on it, and does not cache can satisfy a request with no-store on it, and does not
invalidate it. (Section 5.2.1.5) invalidate it. (Section 5.2.1.5)
The qualified forms of the private and no-cache cache directives are The qualified forms of the private and no-cache cache directives are
noted to not be widely implemented; e.g., "private=foo" is noted to not be widely implemented; e.g., "private=foo" is
interpreted by many caches as simply "private". Additionally, the interpreted by many caches as simply "private". Additionally, the
meaning of the qualified form of no-cache has been clarified. meaning of the qualified form of no-cache has been clarified.
(Section 5.2.2) (Section 5.2.2)
The "no-cache" response cache directive's meaning has been clarified. The "no-cache" response directive's meaning has been clarified.
(Section 5.2.2.2) (Section 5.2.2.2)
The one-year limit on Expires header field values has been removed; The one-year limit on Expires header field values has been removed;
instead, the reasoning for using a sensible value is given. instead, the reasoning for using a sensible value is given.
(Section 5.3) (Section 5.3)
The Pragma header field is now only defined for backwards The Pragma header field is now only defined for backwards
compatibility; future pragmas are deprecated. (Section 5.4) compatibility; future pragmas are deprecated. (Section 5.4)
Some requirements regarding production and processing of the Warning Some requirements regarding production and processing of the Warning
skipping to change at page 40, line 18 skipping to change at page 40, line 18
o <http://tools.ietf.org/wg/httpbis/trac/ticket/499>: "RFC 1305 ref o <http://tools.ietf.org/wg/httpbis/trac/ticket/499>: "RFC 1305 ref
needs to be updated to 5905" needs to be updated to 5905"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/500>: "dangling o <http://tools.ietf.org/wg/httpbis/trac/ticket/500>: "dangling
reference to cacheable status codes" reference to cacheable status codes"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/512>: "APPSDIR o <http://tools.ietf.org/wg/httpbis/trac/ticket/512>: "APPSDIR
review of draft-ietf-httpbis-p6-cache-24" review of draft-ietf-httpbis-p6-cache-24"
D.2. Since draft-ietf-httpbis-p6-cache-25
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/535>: "IESG ballot
on draft-ietf-httpbis-p6-cache-25"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/538>: "add
'stateless' to Abstract"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/542>: "improve
introduction of list rule"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/549>: "augment
security considerations with pointers to current research"
Index Index
1 1
110 (warn-code) 31 110 (warn-code) 30
111 (warn-code) 31 111 (warn-code) 31
112 (warn-code) 31 112 (warn-code) 31
113 (warn-code) 31 113 (warn-code) 31
199 (warn-code) 31 199 (warn-code) 31
2 2
214 (warn-code) 31 214 (warn-code) 31
299 (warn-code) 31 299 (warn-code) 31
A A
skipping to change at page 41, line 48 skipping to change at page 42, line 16
only-if-cached (cache directive) 23 only-if-cached (cache directive) 23
P P
Pragma header field 28 Pragma header field 28
private (cache directive) 25 private (cache directive) 25
private cache 4 private cache 4
proxy-revalidate (cache directive) 26 proxy-revalidate (cache directive) 26
public (cache directive) 25 public (cache directive) 25
R R
Response is Stale (warn-text) 31 Response is Stale (warn-text) 30
Revalidation Failed (warn-text) 31 Revalidation Failed (warn-text) 31
S S
s-maxage (cache directive) 26 s-maxage (cache directive) 26
shared cache 4 shared cache 4
stale 10 stale 10
strong validator 18 strong validator 18
T T
Transformation Applied (warn-text) 31 Transformation Applied (warn-text) 31
 End of changes. 43 change blocks. 
97 lines changed or deleted 112 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/