draft-ietf-httpbis-p6-cache-21.txt | draft-ietf-httpbis-p6-cache-22.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: April 7, 2013 J. Reschke, Ed. | Expires: August 27, 2013 J. Reschke, Ed. | |||
greenbytes | greenbytes | |||
October 4, 2012 | February 23, 2013 | |||
Hypertext Transfer Protocol (HTTP/1.1): Caching | Hypertext Transfer Protocol (HTTP/1.1): Caching | |||
draft-ietf-httpbis-p6-cache-21 | draft-ietf-httpbis-p6-cache-22 | |||
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. This document defines requirements on HTTP caches and the | systems. This document defines requirements on HTTP caches and the | |||
associated header fields that control cache behavior or indicate | associated header fields that control cache behavior or indicate | |||
cacheable response messages. | cacheable response 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.2. | The changes in this draft are summarized in Appendix D.3. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on April 7, 2013. | This Internet-Draft will expire on August 27, 2013. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2012 IETF Trust and the persons identified as the | Copyright (c) 2013 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
skipping to change at page 2, line 44 | skipping to change at page 2, line 44 | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 | 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
1.3. Conformance and Error Handling . . . . . . . . . . . . . . 6 | 1.3. Conformance and Error Handling . . . . . . . . . . . . . . 6 | |||
1.4. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 | 1.4. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 | |||
1.4.1. Delta Seconds . . . . . . . . . . . . . . . . . . . . 6 | 1.4.1. Delta Seconds . . . . . . . . . . . . . . . . . . . . 6 | |||
2. Overview of Cache Operation . . . . . . . . . . . . . . . . . 6 | 2. Overview of Cache Operation . . . . . . . . . . . . . . . . . 6 | |||
3. Storing Responses in Caches . . . . . . . . . . . . . . . . . 7 | 3. Storing Responses in Caches . . . . . . . . . . . . . . . . . 7 | |||
3.1. Storing Incomplete Responses . . . . . . . . . . . . . . . 8 | 3.1. Storing Incomplete Responses . . . . . . . . . . . . . . . 8 | |||
3.2. Storing Responses to Authenticated Requests . . . . . . . 8 | 3.2. Storing Responses to Authenticated Requests . . . . . . . 9 | |||
4. Constructing Responses from Caches . . . . . . . . . . . . . . 9 | 4. Constructing Responses from Caches . . . . . . . . . . . . . . 9 | |||
4.1. Freshness Model . . . . . . . . . . . . . . . . . . . . . 10 | 4.1. Freshness Model . . . . . . . . . . . . . . . . . . . . . 10 | |||
4.1.1. Calculating Freshness Lifetime . . . . . . . . . . . . 11 | 4.1.1. Calculating Freshness Lifetime . . . . . . . . . . . . 11 | |||
4.1.2. Calculating Heuristic Freshness . . . . . . . . . . . 12 | 4.1.2. Calculating Heuristic Freshness . . . . . . . . . . . 12 | |||
4.1.3. Calculating Age . . . . . . . . . . . . . . . . . . . 12 | 4.1.3. Calculating Age . . . . . . . . . . . . . . . . . . . 12 | |||
4.1.4. Serving Stale Responses . . . . . . . . . . . . . . . 14 | 4.1.4. Serving Stale Responses . . . . . . . . . . . . . . . 14 | |||
4.2. Validation Model . . . . . . . . . . . . . . . . . . . . . 15 | 4.2. Validation Model . . . . . . . . . . . . . . . . . . . . . 15 | |||
4.2.1. Freshening Responses with 304 Not Modified . . . . . . 16 | 4.2.1. Freshening Responses with 304 Not Modified . . . . . . 16 | |||
4.3. Using Negotiated Responses . . . . . . . . . . . . . . . . 16 | 4.3. Using Negotiated Responses . . . . . . . . . . . . . . . . 17 | |||
4.4. Combining Partial Content . . . . . . . . . . . . . . . . 17 | 4.4. Combining Partial Content . . . . . . . . . . . . . . . . 17 | |||
5. Updating Caches with HEAD Responses . . . . . . . . . . . . . 18 | 5. Updating Caches with HEAD Responses . . . . . . . . . . . . . 18 | |||
6. Request Methods that Invalidate . . . . . . . . . . . . . . . 18 | 6. Request Methods that Invalidate . . . . . . . . . . . . . . . 19 | |||
7. Header Field Definitions . . . . . . . . . . . . . . . . . . . 19 | 7. Header Field Definitions . . . . . . . . . . . . . . . . . . . 19 | |||
7.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 | 7.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
7.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 20 | 7.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 20 | |||
7.2.1. Request Cache-Control Directives . . . . . . . . . . . 20 | 7.2.1. Request Cache-Control Directives . . . . . . . . . . . 20 | |||
7.2.2. Response Cache-Control Directives . . . . . . . . . . 22 | 7.2.2. Response Cache-Control Directives . . . . . . . . . . 22 | |||
7.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 25 | 7.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 26 | |||
7.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 27 | 7.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 27 | |||
7.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 28 | 7.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 28 | |||
7.5. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 28 | 7.5. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 29 | |||
7.5.1. 110 Response is Stale . . . . . . . . . . . . . . . . 30 | 7.5.1. 110 Response is Stale . . . . . . . . . . . . . . . . 30 | |||
7.5.2. 111 Revalidation Failed . . . . . . . . . . . . . . . 30 | 7.5.2. 111 Revalidation Failed . . . . . . . . . . . . . . . 30 | |||
7.5.3. 112 Disconnected Operation . . . . . . . . . . . . . . 30 | 7.5.3. 112 Disconnected Operation . . . . . . . . . . . . . . 30 | |||
7.5.4. 113 Heuristic Expiration . . . . . . . . . . . . . . . 30 | 7.5.4. 113 Heuristic Expiration . . . . . . . . . . . . . . . 30 | |||
7.5.5. 199 Miscellaneous Warning . . . . . . . . . . . . . . 30 | 7.5.5. 199 Miscellaneous Warning . . . . . . . . . . . . . . 31 | |||
7.5.6. 214 Transformation Applied . . . . . . . . . . . . . . 30 | 7.5.6. 214 Transformation Applied . . . . . . . . . . . . . . 31 | |||
7.5.7. 299 Miscellaneous Persistent Warning . . . . . . . . . 31 | 7.5.7. 299 Miscellaneous Persistent Warning . . . . . . . . . 31 | |||
7.5.8. Warn Code Extensions . . . . . . . . . . . . . . . . . 31 | 7.5.8. Warn Code Extensions . . . . . . . . . . . . . . . . . 31 | |||
8. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 31 | 8. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 31 | |||
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 | 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 | |||
9.1. Cache Directive Registry . . . . . . . . . . . . . . . . . 31 | 9.1. Cache Directive Registry . . . . . . . . . . . . . . . . . 32 | |||
9.2. Warn Code Registry . . . . . . . . . . . . . . . . . . . . 32 | 9.2. Warn Code Registry . . . . . . . . . . . . . . . . . . . . 32 | |||
9.3. Header Field Registration . . . . . . . . . . . . . . . . 33 | 9.3. Header Field Registration . . . . . . . . . . . . . . . . 33 | |||
10. Security Considerations . . . . . . . . . . . . . . . . . . . 33 | 10. Security Considerations . . . . . . . . . . . . . . . . . . . 33 | |||
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 | 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 | |||
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 | 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 | |||
12.1. Normative References . . . . . . . . . . . . . . . . . . . 34 | 12.1. Normative References . . . . . . . . . . . . . . . . . . . 34 | |||
12.2. Informative References . . . . . . . . . . . . . . . . . . 34 | 12.2. Informative References . . . . . . . . . . . . . . . . . . 35 | |||
Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 35 | Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 35 | |||
Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 35 | Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 37 | |||
Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 37 | 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) . . . . . . . . . . . . . . . . . . . . 38 | publication) . . . . . . . . . . . . . . . . . . . . 39 | |||
D.1. Since draft-ietf-httpbis-p6-cache-19 . . . . . . . . . . . 38 | D.1. Since draft-ietf-httpbis-p6-cache-19 . . . . . . . . . . . 39 | |||
D.2. Since draft-ietf-httpbis-p6-cache-20 . . . . . . . . . . . 38 | D.2. Since draft-ietf-httpbis-p6-cache-20 . . . . . . . . . . . 39 | |||
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 | D.3. Since draft-ietf-httpbis-p6-cache-21 . . . . . . . . . . . 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. | |||
1.1. Purpose | 1.1. Purpose | |||
skipping to change at page 4, line 39 | skipping to change at page 4, line 39 | |||
reusable if it can be freshened by validation (Section 4.2) or if the | reusable if it can be freshened by validation (Section 4.2) or if the | |||
origin is unavailable. | origin is unavailable. | |||
1.2. Terminology | 1.2. Terminology | |||
This specification uses a number of terms to refer to the roles | This specification uses a number of terms to refer to the roles | |||
played by participants in, and objects of, HTTP caching. | played by participants in, and objects of, HTTP caching. | |||
cache | cache | |||
A conformant implementation of a HTTP cache. Note that this | A conformant implementation of an HTTP cache. Note that this | |||
implies an HTTP/1.1 cache; this specification does not define | implies an HTTP/1.1 cache; this specification does not define | |||
conformance for HTTP/1.0 caches. | conformance for HTTP/1.0 caches. | |||
shared cache | shared cache | |||
A cache that stores responses to be reused by more than one user; | A cache that stores responses to be reused by more than one user; | |||
usually (but not always) deployed as part of an intermediary. | usually (but not always) deployed as part of an intermediary. | |||
private cache | private cache | |||
skipping to change at page 5, line 15 | skipping to change at page 5, line 15 | |||
cacheable | cacheable | |||
A response is cacheable if a cache is allowed to store a copy of | A response is cacheable if a cache is allowed to store a copy of | |||
the response message for use in answering subsequent requests. | the response message for use in answering subsequent requests. | |||
Even when a response is cacheable, there might be additional | Even when a response is cacheable, there might be additional | |||
constraints on whether a cache can use the stored copy to satisfy | constraints on whether a cache can use the stored copy to satisfy | |||
a particular request. | a particular request. | |||
explicit expiration time | explicit expiration time | |||
The time at which the origin server intends that a representation | The time at which the origin server intends that a stored response | |||
no longer be returned by a cache without further validation. | no longer be used by a cache without further validation. | |||
heuristic expiration time | heuristic expiration time | |||
An expiration time assigned by a cache when no explicit expiration | An expiration time assigned by a cache when no explicit expiration | |||
time is available. | time is available. | |||
age | age | |||
The age of a response is the time since it was sent by, or | The age of a response is the time since it was sent by, or | |||
successfully validated with, the origin server. | successfully validated with, the origin server. | |||
skipping to change at page 7, line 9 | skipping to change at page 7, line 9 | |||
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, we assume that reusing the cached response is desirable and | |||
that such reuse is the default behavior when no requirement or | that such reuse is the default behavior when no requirement or | |||
locally-desired configuration prevents it. Therefore, HTTP cache | locally-desired configuration prevents it. Therefore, HTTP cache | |||
requirements are focused on preventing a cache from either storing a | requirements are focused on preventing a cache from either storing a | |||
non-reusable response or reusing a stored response inappropriately. | non-reusable response or reusing a stored response inappropriately. | |||
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 containing a | retrieval request: i.e., a 200 (OK) response to a GET request, which | |||
representation of the resource identified by the request target. | contains a representation of the resource identified by the request | |||
However, it is also possible to cache negative results (e.g., 404 | target (Section 4.3.1 of [Part2]). However, it is also possible to | |||
(Not Found), incomplete results (e.g., 206 (Partial Content)), and | cache permanent redirects, negative results (e.g., 404 (Not Found)), | |||
responses to methods other than GET if the method's definition allows | incomplete results (e.g., 206 (Partial Content)), and responses to | |||
such caching and defines something suitable for use as a cache key. | methods other than GET if the method's definition allows such 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, many implementations simply decline | to caching responses to GET, many 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 4.3). | header fields (Section 4.3). | |||
skipping to change at page 8, line 11 | skipping to change at page 8, line 11 | |||
* contains a max-age response cache directive (see | * contains a max-age response cache directive (see | |||
Section 7.2.2.7), or | Section 7.2.2.7), 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 | |||
* contains a Cache Control Extension (see Section 7.2.3) that | * contains a Cache Control Extension (see Section 7.2.3) that | |||
allows it to be cached, or | allows it to be cached, or | |||
* has a status code that can be served with heuristic freshness | * has a status code that is defined as cacheable (see | |||
(see Section 4.1.2). | Section 4.1.2), or | |||
* contains a public response cache directive (see | ||||
Section 7.2.2.1). | ||||
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 7.2.3. | cache-control extension; see Section 7.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 any cache- | response status code if it recognizes it and implements any cache- | |||
specific behavior. | specific behavior. | |||
Note that, in normal operation, many caches will not store a response | Note that, in normal operation, many 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 9, line 20 | skipping to change at page 9, line 25 | |||
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.1.4) by shared caches. In particular, a response with | (Section 4.1.4) 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. | |||
4. Constructing Responses from Caches | 4. Constructing Responses from Caches | |||
For a presented request, a cache MUST NOT return a stored response, | For a presented request, a cache MUST NOT send a stored response, | |||
unless: | unless: | |||
o The presented effective request URI (Section 5.5 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 4.3), and | match those presented (see Section 4.3), and | |||
skipping to change at page 9, line 46 | skipping to change at page 10, line 4 | |||
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 7.2.2.3), unless it is successfully validated | (Section 7.2.2.3), unless it is successfully validated | |||
(Section 4.2), and | (Section 4.2), and | |||
o the stored response is either: | o the stored response is either: | |||
* fresh (see Section 4.1), or | * fresh (see Section 4.1), or | |||
* allowed to be served stale (see Section 4.1.4), or | * allowed to be served stale (see Section 4.1.4), or | |||
* successfully validated (see Section 4.2). | * successfully validated (see Section 4.2). | |||
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 7.2.3. | cache-control extension; see Section 7.2.3. | |||
When a stored response is used to satisfy a request without | When a stored response is used to satisfy a request without | |||
validation, a cache MUST include a single Age header field | validation, a cache MUST send a single Age header field (Section 7.1) | |||
(Section 7.1) in the response with a value equal to the stored | in the response with a value equal to the stored response's | |||
response's current_age; see Section 4.1.3. | current_age; see Section 4.1.3. | |||
A cache MUST write through requests with methods that are unsafe | A cache MUST write through requests with methods that are unsafe | |||
(Section 5.2.1 of [Part2]) to the origin server; i.e., a cache is not | (Section 4.2.1 of [Part2]) to the origin server; i.e., a cache is not | |||
allowed to generate a reply to such a request before having forwarded | allowed to generate a reply to such a request before having forwarded | |||
the request and having received a corresponding response. | the 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 6. | responses; see Section 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. | |||
especially a shared cache, SHOULD use a mechanism, such as NTP | ||||
[RFC1305], to synchronize its clock with a reliable external | ||||
standard. | ||||
4.1. Freshness Model | 4.1. Freshness Model | |||
When a response is "fresh" in the cache, it can be used to satisfy | When a response is "fresh" in the cache, it can be used to satisfy | |||
subsequent requests without contacting the origin server, thereby | subsequent requests without contacting the origin server, thereby | |||
improving efficiency. | improving efficiency. | |||
The primary mechanism for determining freshness is for an origin | The primary mechanism for determining freshness is for an origin | |||
server to provide an explicit expiration time in the future, using | server to provide an explicit expiration time in the future, using | |||
either the Expires header field (Section 7.3) or the max-age response | either the Expires header field (Section 7.3) or the max-age response | |||
cache directive (Section 7.2.2.7). Generally, origin servers will | cache directive (Section 7.2.2.7). Generally, origin servers will | |||
assign future explicit expiration times to responses in the belief | assign future explicit expiration times to responses in the belief | |||
that the representation is not likely to change in a semantically | that the representation is not likely to change in a semantically | |||
significant way before the expiration time is reached. | significant way before the expiration time is reached. | |||
If an origin server wishes to force a cache to validate every | If an origin server wishes to force a cache to validate every | |||
request, it can assign an explicit expiration time in the past to | request, it can assign an explicit expiration time in the past to | |||
indicate that the response is already stale. Compliant caches will | indicate that the response is already stale. Compliant caches will | |||
normally validate the cached response before reusing it for | normally validate a stale cached response before reusing it for | |||
subsequent requests (see Section 4.1.4). | subsequent requests (see Section 4.1.4). | |||
Since origin servers do not always provide explicit expiration times, | Since origin servers do not always provide explicit expiration times, | |||
a cache MAY assign a heuristic expiration time when an explicit time | caches are also allowed to use a heuristic to determine an expiration | |||
is not specified, employing algorithms that use other header field | time under certain circumstances (see Section 4.1.2). | |||
values (such as the Last-Modified time) to estimate a plausible | ||||
expiration time. This specification does not provide specific | ||||
algorithms, but does impose worst-case constraints on their results. | ||||
The calculation to determine if a response is fresh is: | The calculation to determine if a response is fresh is: | |||
response_is_fresh = (freshness_lifetime > current_age) | response_is_fresh = (freshness_lifetime > current_age) | |||
The freshness_lifetime is defined in Section 4.1.1; the current_age | The freshness_lifetime is defined in Section 4.1.1; the current_age | |||
is defined in Section 4.1.3. | is defined in Section 4.1.3. | |||
Additionally, clients can influence freshness calculation -- either | Clients can send the max-age or min-fresh cache directives in a | |||
constraining it relaxing it -- by using the max-age and min-fresh | request to constrain or relax freshness calculations for the | |||
request cache directives. See Section 7.2.1 for details. | corresponding response (Section 7.2.1). | |||
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 8 for an explanation of the difference between | resource. See Section 8 for an explanation of the difference between | |||
caches and history mechanisms. | caches and history mechanisms. | |||
4.1.1. Calculating Freshness Lifetime | 4.1.1. Calculating Freshness Lifetime | |||
A cache can calculate the freshness lifetime (denoted as | A cache can calculate the freshness lifetime (denoted as | |||
freshness_lifetime) of a response by using the first match of: | freshness_lifetime) of a response by using the first match of: | |||
skipping to change at page 12, line 7 | skipping to change at page 12, line 7 | |||
of the information comes from the origin server. | of the information comes from the origin server. | |||
When there is more than one value present for a given directive | When there is more than one value present for a given directive | |||
(e.g., two Expires header fields, multiple Cache-Control: max-age | (e.g., two Expires header fields, multiple Cache-Control: max-age | |||
directives), it is considered invalid. Caches are encouraged to | directives), it is considered invalid. Caches are encouraged to | |||
consider responses that have invalid freshness information to be | consider responses that have invalid freshness information to be | |||
stale. | stale. | |||
4.1.2. Calculating Heuristic Freshness | 4.1.2. Calculating Heuristic Freshness | |||
If no explicit expiration time is present in a stored response that | Since origin servers do not always provide explicit expiration times, | |||
has a status code whose definition allows heuristic freshness to be | a cache MAY assign a heuristic expiration time when an explicit time | |||
used (including the following in Section 7 of [Part2]: 200 (OK), 203 | is not specified, employing algorithms that use other header field | |||
(Non-Authoritative Information), 206 (Partial Content), 300 (Multiple | values (such as the Last-Modified time) to estimate a plausible | |||
Choices), 301 (Moved Permanently) and 410 (Gone)), a cache MAY | expiration time. This specification does not provide specific | |||
calculate a heuristic expiration time. A cache MUST NOT use | algorithms, but does impose worst-case constraints on their results. | |||
heuristics to determine freshness for responses with status codes | ||||
that do not explicitly allow it. | A cache MUST NOT use heuristics to determine freshness when an | |||
explicit expiration time is present in the stored response. Because | ||||
of the requirements in Section 3, this means that, effectively, | ||||
heuristics can only be used on responses without explicit freshness | ||||
whose status codes are defined as cacheable, and responses without | ||||
explicit freshness that have been marked as explicitly cacheable | ||||
(e.g., with a "public" response cache directive). | ||||
If the response has a Last-Modified header field (Section 2.2 of | ||||
[Part4]), caches are encouraged to use a heuristic expiration value | ||||
that is no more than some fraction of the interval since that time. | ||||
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 attach a Warning header field with a 113 warn-code to the | SHOULD attach a Warning header field with a 113 warn-code to the | |||
response if its current_age is more than 24 hours and such a warning | response if its current_age is more than 24 hours and such a warning | |||
is not already present. | is not already present. | |||
Also, if the response has a Last-Modified header field (Section 2.2 | ||||
of [Part4]), caches are encouraged to use a heuristic expiration | ||||
value that is no more than some fraction of the interval since that | ||||
time. A typical setting of this fraction might be 10%. | ||||
Note: Section 13.9 of [RFC2616] prohibited caches from calculating | Note: Section 13.9 of [RFC2616] prohibited caches from calculating | |||
heuristic freshness for URIs with query components (i.e., those | heuristic freshness for URIs with query components (i.e., those | |||
containing '?'). In practice, this has not been widely | containing '?'). In practice, this has not been widely | |||
implemented. Therefore, servers are encouraged to send explicit | implemented. Therefore, servers are encouraged to send explicit | |||
directives (e.g., Cache-Control: no-cache) if they wish to | directives (e.g., Cache-Control: no-cache) if they wish to | |||
preclude caching. | preclude caching. | |||
4.1.3. Calculating Age | 4.1.3. Calculating Age | |||
HTTP/1.1 uses the Age header field to convey the estimated age of the | The Age header field is used to convey an estimated age of the | |||
response message when obtained from a cache. The Age field value is | response message when obtained from a cache. The Age field value is | |||
the cache's estimate of the amount of time since the response was | the cache's estimate of the number of seconds since the response was | |||
generated or validated by the origin server. In essence, the Age | generated or validated by the origin server. In essence, the Age | |||
value is the sum of the time that the response has been resident in | value is the sum of the time that the response has been resident in | |||
each of the caches along the path from the origin server, plus the | each of the caches along the path from the origin server, plus the | |||
amount of time it has been in transit along network paths. | amount of time it has been in transit along network paths. | |||
The following data is used for the age calculation: | The following data is used for the age calculation: | |||
age_value | age_value | |||
The term "age_value" denotes the value of the Age header field | The term "age_value" denotes the value of the Age header field | |||
(Section 7.1), in a form appropriate for arithmetic operation; or | (Section 7.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 | The term "date_value" denotes the value of the Date header field, | |||
possible, with every response, giving the time at which the | in a form appropriate for arithmetic operations. See Section | |||
response was generated. The term "date_value" denotes the value | 7.1.1.2 of [Part2] for the definition of the Date header field, | |||
of the Date header field, in a form appropriate for arithmetic | and for requirements regarding responses without it. | |||
operations. See Section 8.1.1.2 of [Part2] for the definition of | ||||
the Date header field, and for requirements regarding responses | ||||
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 host ought to use NTP ([RFC1305]) | |||
or some similar protocol to synchronize its clocks to a globally | or some similar protocol to synchronize its clocks to Coordinated | |||
accurate time standard. | Universal Time. | |||
request_time | request_time | |||
The current value of the clock at the host at the time the request | The current value of the clock at the host at the time the request | |||
resulting in the stored response was made. | resulting in the stored response was made. | |||
response_time | response_time | |||
The current value of the clock at the host at the time the | The current value of the clock at the host at the time the | |||
response was received. | response was received. | |||
skipping to change at page 14, line 23 | skipping to change at page 14, line 23 | |||
The current_age of a stored response can then be calculated by adding | The current_age of a stored response can then be calculated by adding | |||
the amount of time (in seconds) since the stored response was last | the amount of time (in seconds) since the stored response was last | |||
validated by the origin server to the corrected_initial_age. | validated by the origin server to the corrected_initial_age. | |||
resident_time = now - response_time; | resident_time = now - response_time; | |||
current_age = corrected_initial_age + resident_time; | current_age = corrected_initial_age + resident_time; | |||
Additionally, to avoid common problems in date parsing: | Additionally, to avoid common problems in date parsing: | |||
o Recipients SHOULD assume that an RFC-850 date which appears to be | ||||
more than 50 years in the future is in fact in the past (this | ||||
helps solve the "year 2000" problem). | ||||
o Although all date formats are specified to be case-sensitive, | o Although all date formats are specified to be case-sensitive, | |||
recipients SHOULD match day, week and timezone names case- | cache recipients SHOULD match day, week and timezone names case- | |||
insensitively. | insensitively. | |||
o An implementation MAY internally represent a parsed Expires date | o If a cache recipient's internal implementation of time has less | |||
as earlier than the proper value, but MUST NOT internally | resolution than the value of an HTTP-date, the recipient MUST | |||
represent a parsed Expires date as later than the proper value. | internally represent a parsed Expires date as the nearest time | |||
equal to or earlier than the received value. | ||||
o Recipients MUST perform all expiration-related calculations in | o Cache recipients MUST NOT allow local time zones to influence the | |||
GMT. The local time zone MUST NOT influence the calculation or | calculation or comparison of an age or expiration time. | |||
comparison of an age or expiration time. | ||||
o Caches SHOULD consider dates with time zones other than "GMT" | o Cache recipients SHOULD consider a date with a zone abbreviation | |||
invalid. | other than "GMT" to be invalid for calculating expiration. | |||
4.1.4. Serving Stale Responses | 4.1.4. Serving Stale Responses | |||
A "stale" response is one that either has explicit expiry information | A "stale" response is one that either has explicit expiry information | |||
or is allowed to have heuristic expiry calculated, but is not fresh | or is allowed to have heuristic expiry calculated, but is not fresh | |||
according to the calculations in Section 4.1. | according to the calculations in Section 4.1. | |||
A cache MUST NOT return a stale response if it is prohibited by an | A cache MUST NOT send a stale response if it is prohibited by an | |||
explicit in-protocol directive (e.g., by a "no-store" or "no-cache" | explicit in-protocol directive (e.g., by a "no-store" or "no-cache" | |||
cache directive, a "must-revalidate" cache-response-directive, or an | cache directive, a "must-revalidate" cache-response-directive, or an | |||
applicable "s-maxage" or "proxy-revalidate" cache-response-directive; | applicable "s-maxage" or "proxy-revalidate" cache-response-directive; | |||
see Section 7.2.2). | see Section 7.2.2). | |||
A cache MUST NOT return stale responses unless it is disconnected | A cache MUST NOT send stale responses unless it is disconnected | |||
(i.e., it cannot contact the origin server or otherwise find a | (i.e., it cannot contact the origin server or otherwise find a | |||
forward path) or doing so is explicitly allowed (e.g., by the max- | forward path) or doing so is explicitly allowed (e.g., by the max- | |||
stale request directive; see Section 7.2.1). | stale request directive; see Section 7.2.1). | |||
A cache SHOULD append a Warning header field with the 110 warn-code | A cache SHOULD append a Warning header field with the 110 warn-code | |||
(see Section 7.5) to stale responses. Likewise, a cache SHOULD add | (see Section 7.5) to stale responses. Likewise, a cache SHOULD add | |||
the 112 warn-code to stale responses if the cache is disconnected. | the 112 warn-code to stale responses if the cache is disconnected. | |||
If a cache receives a first-hand response (either an entire response, | If a cache receives a first-hand response (either an entire response, | |||
or a 304 (Not Modified) response) that it would normally forward to | or a 304 (Not Modified) response) that it would normally forward to | |||
skipping to change at page 16, line 9 | skipping to change at page 16, line 8 | |||
stored response can be updated and reused; see Section 4.2.1. | stored response can be updated and reused; see Section 4.2.1. | |||
o A full response (i.e., one with a payload body) indicates that | o A full response (i.e., one with a payload body) indicates that | |||
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 (Server Error) response while | o However, if a cache receives a 5xx (Server Error) response while | |||
attempting to validate a response, it can either forward this | attempting to validate a response, it can either forward this | |||
response to the requesting client, or act as if the server failed | response to the requesting client, or act as if the server failed | |||
to respond. In the latter case, it can return a previously stored | to respond. In the latter case, it can send a previously stored | |||
response (see Section 4.1.4). | response (see Section 4.1.4). | |||
4.2.1. Freshening Responses with 304 Not Modified | 4.2.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. | |||
The stored response to update is identified by using the first match | ||||
(if any) of: | ||||
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 | |||
none of the stored responses contain the same strong validator, | none of the stored responses contain the same strong validator, | |||
then this new response corresponds to a new selected | then the new response MUST NOT be used to update any stored | |||
representation and MUST NOT update the existing stored responses. | responses. | |||
o If the new response contains a weak validator and that validator | o If the new response contains a weak validator and that validator | |||
corresponds to one of the cache's stored responses, then the most | corresponds to one of the cache's stored responses, then the most | |||
recent of those matching stored responses is selected. | recent of those matching stored responses is selected. | |||
o If the new response does not include any form of validator, there | o If the new response does not include any form of validator (such | |||
is only one stored response, and that stored response also lacks a | as in the case where a client generates an If-Modified-Since | |||
validator, then that stored response is selected. | request from a source other than the Last-Modified response header | |||
field), and there is only one stored response, and that stored | ||||
response also lacks a validator, then that stored response is | ||||
selected. | ||||
If a stored response is selected for update, the cache MUST: | If a stored response is selected for update, 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 7.5); | code 1xx (see Section 7.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, | |||
o use other header fields provided in the 304 (Not Modified) | o use other header fields provided in the 304 (Not Modified) | |||
response to replace all instances of the corresponding header | response to replace all instances of the corresponding header | |||
fields in the stored response. | fields in the stored response. | |||
4.3. Using Negotiated Responses | 4.3. Using 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 8.2.1 of [Part2]), it | response that has a Vary header field (Section 7.1.4 of [Part2]), it | |||
MUST NOT use that response unless all of the selecting header fields | MUST NOT use that response unless all of the selecting header fields | |||
nominated by the Vary header field match in both the original request | nominated by the Vary header field match in both the original request | |||
(i.e., that associated with the stored response), and the presented | (i.e., that associated with the stored response), and the presented | |||
request. | 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: | |||
o adding or removing whitespace, where allowed in the header field's | o adding or removing whitespace, where allowed in the header field's | |||
skipping to change at page 17, line 39 | skipping to change at page 17, line 45 | |||
subsequent requests to that resource can only be properly interpreted | subsequent requests to that resource can only be properly interpreted | |||
by the origin server. | by the origin server. | |||
The stored response with matching selecting header fields is known as | The stored response with matching selecting header fields is known as | |||
the selected response. | the selected response. | |||
If multiple selected responses are available, the most recent | 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 4. | Section 4. | |||
If no selected response is available, the cache can forward the | If no selected response is available, the cache cannot satisfy the | |||
presented request to the origin server in a conditional request; see | presented request. Typically, it is forwarded to the origin server | |||
Section 4.2. | in a (possibly conditional; see Section 4.2) request. | |||
4.4. Combining Partial Content | 4.4. 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.2 of [Part5]. | requirements in Section 4.3 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 7.5); | code 1xx (see Section 7.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 18, line 49 | skipping to change at page 19, line 7 | |||
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 response to replace all | o use other header fields provided in the response to replace all | |||
instances of the corresponding header fields in the stored | instances of the corresponding header fields in the stored | |||
response. | response. | |||
6. Request Methods that Invalidate | 6. Request Methods that Invalidate | |||
Because unsafe request methods (Section 5.2.1 of [Part2]) such as | Because unsafe request methods (Section 4.2.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 5.5 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 | |||
response header fields (if present) when a non-error response to a | response header fields (if present) when a non-error response to a | |||
request 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 | |||
skipping to change at page 19, line 24 | skipping to change at page 19, line 30 | |||
of [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 5.5 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 (Successful) or 3xx | Here, a "non-error response" is one with a 2xx (Successful) or 3xx | |||
(Redirection) status code. "Invalidate" means that the cache will | (Redirection) status code. "Invalidate" means that the cache will | |||
either remove all stored responses related to the effective request | either remove all stored responses related to the effective request | |||
URI, or will mark these as "invalid" and in need of a mandatory | URI, or will mark these as "invalid" and in need of a mandatory | |||
validation before they can be returned in response to a subsequent | validation before they can be sent in response to a subsequent | |||
request. | 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. | |||
7. Header Field Definitions | 7. Header Field Definitions | |||
This section defines the syntax and semantics of HTTP/1.1 header | This section defines the syntax and semantics of HTTP/1.1 header | |||
skipping to change at page 22, line 24 | skipping to change at page 22, line 28 | |||
client wants a response that will still be fresh for at least the | client wants a response that will still be fresh for at least the | |||
specified number of seconds. | specified number of seconds. | |||
Note: This directive uses the token form of the argument syntax; | Note: This directive uses the token form of the argument syntax; | |||
e.g., 'min-fresh=20', not 'min-fresh="20"'. Senders SHOULD NOT use | e.g., 'min-fresh=20', not 'min-fresh="20"'. Senders SHOULD NOT use | |||
the quoted-string form. | the quoted-string form. | |||
7.2.1.6. no-transform | 7.2.1.6. no-transform | |||
The "no-transform" request directive indicates that an intermediary | The "no-transform" request directive indicates that an intermediary | |||
(whether or not it implements a cache) MUST NOT change the Content- | (whether or not it implements a cache) MUST NOT transform the | |||
Encoding, Content-Range or Content-Type request header fields, nor | payload, as defined in Section 5.7.2 of [Part1]. | |||
the request representation. | ||||
7.2.1.7. only-if-cached | 7.2.1.7. only-if-cached | |||
The "only-if-cached" request directive indicates that the client only | The "only-if-cached" request directive indicates that the client only | |||
wishes to obtain a stored response. If it receives this directive, a | wishes to obtain a stored response. If it receives this directive, a | |||
cache SHOULD either respond using a stored response that is | cache SHOULD either respond using a stored response that is | |||
consistent with the other constraints of the request, or respond with | consistent with the other constraints of the request, or respond with | |||
a 504 (Gateway Timeout) status code. If a group of caches is being | a 504 (Gateway Timeout) status code. If a group of caches is being | |||
operated as a unified system with good internal connectivity, a | operated as a unified system with good internal connectivity, a | |||
member cache MAY forward such a request within that group of caches. | member cache MAY forward such a request within that group of caches. | |||
7.2.2. Response Cache-Control Directives | 7.2.2. Response Cache-Control Directives | |||
7.2.2.1. public | 7.2.2.1. public | |||
The "public" response directive indicates that a response whose | The "public" response directive indicates that any cache MAY store | |||
associated request contains an 'Authentication' header MAY be stored | the response, even if the response would normally be non-cacheable or | |||
(see Section 3.2). | cacheable only within a non-shared cache. (See Section 3.2 for | |||
additional details related to the use of public in response to a | ||||
request containing Authorization, and Section 3 for details of how | ||||
public affects responses that would normally not be stored, due to | ||||
their status codes not being defined as cacheable.) | ||||
7.2.2.2. private | 7.2.2.2. private | |||
Argument syntax: | Argument syntax: | |||
#field-name | #field-name | |||
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 and reuse it for later | |||
requests, even if the response would normally be non-cacheable. | ||||
If the private response directive specifies one or more field-names, | If the private response directive specifies one or more field-names, | |||
this requirement is limited to the field-values associated with the | this requirement is limited to the field-values associated with the | |||
listed response header fields. That is, a shared cache MUST NOT | listed response header fields. That is, a shared cache MUST NOT | |||
store the specified field-names(s), whereas it MAY store the | store the specified field-names(s), whereas it MAY store the | |||
remainder of the response message. | remainder of the response message. | |||
The field-names given are not limited to the set of standard header | The field-names given are not limited to the set of standard header | |||
fields defined by this specification. Field names are case- | fields defined by this specification. Field names are case- | |||
insensitive. | insensitive. | |||
skipping to change at page 23, line 38 | skipping to change at page 23, line 47 | |||
7.2.2.3. no-cache | 7.2.2.3. no-cache | |||
Argument syntax: | Argument syntax: | |||
#field-name | #field-name | |||
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 contacting | prevent a cache from using it to satisfy a request without contacting | |||
it, even by caches that have been configured to return stale | it, even by caches that have been configured to send stale responses. | |||
responses. | ||||
If the no-cache response directive specifies one or more field-names, | If the no-cache response directive specifies one or more field-names, | |||
then a cache MAY use the response to satisfy a subsequent request, | then a cache MAY use the response to satisfy a subsequent request, | |||
subject to any other restrictions on caching. However, any header | subject to any other restrictions on caching. However, any header | |||
fields in the response that have the field-name(s) listed MUST NOT be | fields in the response that have the field-name(s) listed MUST NOT be | |||
sent in the response to a subsequent request without successful | sent in the response to a subsequent request without successful | |||
revalidation with the origin server. This allows an origin server to | revalidation with the origin server. This allows an origin server to | |||
prevent the re-use of certain header fields in a response, while | prevent the re-use of certain header fields in a response, while | |||
still allowing caching of the rest of the response. | still allowing caching of the rest of the response. | |||
skipping to change at page 25, line 39 | skipping to change at page 25, line 46 | |||
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. | |||
Note: This directive uses the token form of the argument syntax; | Note: This directive uses the token form of the argument syntax; | |||
e.g., 's-maxage=10', not 's-maxage="10"'. Senders SHOULD NOT use the | e.g., 's-maxage=10', not 's-maxage="10"'. Senders SHOULD NOT use the | |||
quoted-string form. | quoted-string form. | |||
7.2.2.9. no-transform | 7.2.2.9. no-transform | |||
The "no-transform" response directive indicates that an intermediary | The "no-transform" response directive indicates that an intermediary | |||
(regardless of whether it implements a cache) MUST NOT change the | (regardless of whether it implements a cache) MUST NOT transform the | |||
Content-Encoding, Content-Range or Content-Type response header | payload, as defined in Section 5.7.2 of [Part1]. | |||
fields, nor the response representation. | ||||
7.2.3. Cache Control Extensions | 7.2.3. Cache Control Extensions | |||
The Cache-Control header field can be extended through the use of one | The Cache-Control header field can be extended through the use of one | |||
or more cache-extension tokens, each with an optional value. | or more cache-extension tokens, each with an optional value. | |||
Informational extensions (those that do not require a change in cache | Informational extensions (those that do not require a change in cache | |||
behavior) can be added without changing the semantics of other | behavior) can be added without changing the semantics of other | |||
directives. Behavioral extensions are designed to work by acting as | directives. Behavioral extensions are designed to work by acting as | |||
modifiers to the existing base of cache directives. Both the new | modifiers to the existing base of cache directives. Both the new | |||
directive and the standard directive are supplied, such that | directive and the standard directive are supplied, such that | |||
skipping to change at page 27, line 25 | skipping to change at page 27, line 33 | |||
7.3. Expires | 7.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.1 for further discussion | response is considered stale. See Section 4.1 for further discussion | |||
of the freshness model. | of the freshness model. | |||
The presence of an Expires field does not imply that the original | The presence of an Expires field does not imply that the original | |||
resource will change or cease to exist at, before, or after that | resource will change or cease to exist at, before, or after that | |||
time. | time. | |||
The field-value is an absolute date and time as defined by HTTP-date | The Expires value is an HTTP-date timestamp, as defined in Section | |||
in Section 8.1.1.1 of [Part2]; a sender MUST use the rfc1123-date | 7.1.1.1 of [Part2]. | |||
format. | ||||
Expires = HTTP-date | Expires = HTTP-date | |||
For example | For example | |||
Expires: Thu, 01 Dec 1994 16:00:00 GMT | Expires: Thu, 01 Dec 1994 16:00:00 GMT | |||
A cache MUST treat other invalid date formats, especially including | A cache recipient MUST interpret invalid date formats, especially the | |||
the value "0", as in the past (i.e., "already expired"). | value "0", as representing a time in the past (i.e., "already | |||
expired"). | ||||
Note: If a response includes a Cache-Control field with the max- | If a response includes a Cache-Control field with the max-age | |||
age directive (see Section 7.2.2.7), that directive overrides the | directive (Section 7.2.2.7), a recipient MUST ignore the Expires | |||
Expires field. Likewise, the s-maxage directive (Section 7.2.2.8) | field. Likewise, if a response includes the s-maxage directive | |||
overrides the Expires header fieldin shared caches. | (Section 7.2.2.8), a shared cache recipient MUST ignore the Expires | |||
field. In both these cases, the value in Expires is only intended | ||||
for recipients that have not yet implemented the Cache-Control field. | ||||
An origin server without a clock MUST NOT generate an Expires field | ||||
unless its value represents a fixed time in the past (always expired) | ||||
or its value has been associated with the resource by a system or | ||||
user with a reliable clock. | ||||
Historically, HTTP required the Expires field-value to be no more | Historically, HTTP required the Expires field-value to be no more | |||
than a year in the future. While longer freshness lifetimes are no | than a year in the future. While longer freshness lifetimes are no | |||
longer prohibited, extremely large values have been demonstrated to | longer prohibited, extremely large values have been demonstrated to | |||
cause problems (e.g., clock overflows due to use of 32-bit integers | cause problems (e.g., clock overflows due to use of 32-bit integers | |||
for time values), and many caches will evict a response far sooner | for time values), and many caches will evict a response far sooner | |||
than that. Therefore, senders ought not produce them. | than that. | |||
An origin server without a clock MUST NOT assign Expires values to a | ||||
response unless these values were associated with the resource by a | ||||
system or user with a reliable clock. It MAY assign an Expires value | ||||
that is known, at or before server configuration time, to be in the | ||||
past (this allows "pre-expiration" of responses without storing | ||||
separate Expires values for each resource). | ||||
7.4. Pragma | 7.4. Pragma | |||
The "Pragma" header field allows backwards compatibility with | The "Pragma" header field allows backwards compatibility with | |||
HTTP/1.0 caches, so that clients can specify a "no-cache" request | HTTP/1.0 caches, so that clients can specify a "no-cache" request | |||
that they will understand (as Cache-Control was not defined until | that they will understand (as Cache-Control was not defined until | |||
HTTP/1.1). When the Cache-Control header field is also present and | HTTP/1.1). When the Cache-Control header field is also present and | |||
understood in a request, Pragma is ignored. | understood in a request, Pragma is ignored. | |||
In HTTP/1.0, Pragma was defined as an extensible field for | In HTTP/1.0, Pragma was defined as an extensible field for | |||
skipping to change at page 29, line 50 | skipping to change at page 30, line 13 | |||
response after validation: | response after validation: | |||
o 1xx Warnings describe the freshness or validation status of the | o 1xx Warnings describe the freshness or validation status of the | |||
response, and so MUST be deleted by a cache after validation. | response, and so MUST be deleted by a cache after validation. | |||
They can only be generated by a cache when validating a cached | They can only be generated by a cache when validating a cached | |||
entry, and MUST NOT be generated in any other situation. | entry, and MUST NOT be generated in any other situation. | |||
o 2xx Warnings describe some aspect of the representation that is | o 2xx Warnings describe some aspect of the representation that is | |||
not rectified by a validation (for example, a lossy compression of | not rectified by a validation (for example, a lossy compression of | |||
the representation) and MUST NOT be deleted by a cache after | the representation) and MUST NOT be deleted by a cache after | |||
validation, unless a full response is returned, in which case they | validation, unless a full response is sent, in which case they | |||
MUST be. | MUST be. | |||
If an implementation sends a message with one or more Warning header | If an implementation sends a message with one or more Warning header | |||
fields to a receiver whose version is HTTP/1.0 or lower, then the | fields to a receiver whose version is HTTP/1.0 or lower, then the | |||
sender MUST include in each warning-value a warn-date that matches | sender MUST include in each warning-value a warn-date that matches | |||
the Date header field in the message. | the Date header field in the message. | |||
If a system receives a message with a warning-value that includes a | If a system receives a message with a warning-value that includes a | |||
warn-date, and that warn-date is different from the Date value in the | warn-date, and that warn-date is different from the Date value in the | |||
response, then that warning-value MUST be deleted from the message | response, then that warning-value MUST be deleted from the message | |||
before storing, forwarding, or using it. (preventing the consequences | before storing, forwarding, or using it. (preventing the consequences | |||
of naive caching of Warning header fields.) If all of the warning- | of naive caching of Warning header fields.) If all of the warning- | |||
values are deleted for this reason, the Warning header field MUST be | values are deleted for this reason, the Warning header field MUST be | |||
deleted as well. | deleted as well. | |||
The following warn-codes are defined by this specification, each with | The following warn-codes are defined by this specification, each with | |||
a recommended warn-text in English, and a description of its meaning. | a recommended warn-text in English, and a description of its meaning. | |||
7.5.1. 110 Response is Stale | 7.5.1. 110 Response is Stale | |||
A cache SHOULD include this whenever the returned response is stale. | A cache SHOULD generate this whenever the sent response is stale. | |||
7.5.2. 111 Revalidation Failed | 7.5.2. 111 Revalidation Failed | |||
A cache SHOULD include this when returning a stale response because | A cache SHOULD generate this when sending a stale response because an | |||
an attempt to validate the response failed, due to an inability to | attempt to validate the response failed, due to an inability to reach | |||
reach the server. | the server. | |||
7.5.3. 112 Disconnected Operation | 7.5.3. 112 Disconnected Operation | |||
A cache SHOULD include this if it is intentionally disconnected from | A cache SHOULD generate this if it is intentionally disconnected from | |||
the rest of the network for a period of time. | the rest of the network for a period of time. | |||
7.5.4. 113 Heuristic Expiration | 7.5.4. 113 Heuristic Expiration | |||
A cache SHOULD include this if it heuristically chose a freshness | A cache SHOULD generate this if it heuristically chose a freshness | |||
lifetime greater than 24 hours and the response's age is greater than | lifetime greater than 24 hours and the response's age is greater than | |||
24 hours. | 24 hours. | |||
7.5.5. 199 Miscellaneous Warning | 7.5.5. 199 Miscellaneous Warning | |||
The warning text can include arbitrary information to be presented to | The warning text can include arbitrary information to be presented to | |||
a human user, or logged. A system receiving this warning MUST NOT | a human user, or logged. A system receiving this warning MUST NOT | |||
take any automated action, besides presenting the warning to the | take any automated action, besides presenting the warning to the | |||
user. | user. | |||
skipping to change at page 33, line 9 | skipping to change at page 33, line 21 | |||
| 113 | Heuristic Expiration | Section 7.5.4 | | | 113 | Heuristic Expiration | Section 7.5.4 | | |||
| 199 | Miscellaneous Warning | Section 7.5.5 | | | 199 | Miscellaneous Warning | Section 7.5.5 | | |||
| 214 | Transformation Applied | Section 7.5.6 | | | 214 | Transformation Applied | Section 7.5.6 | | |||
| 299 | Miscellaneous Persistent Warning | Section 7.5.7 | | | 299 | Miscellaneous Persistent Warning | Section 7.5.7 | | |||
+-----------+----------------------------------+---------------+ | +-----------+----------------------------------+---------------+ | |||
9.3. Header Field Registration | 9.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 [BCP90]): | |||
+-------------------+----------+----------+-------------+ | +-------------------+----------+----------+-------------+ | |||
| Header Field Name | Protocol | Status | Reference | | | Header Field Name | Protocol | Status | Reference | | |||
+-------------------+----------+----------+-------------+ | +-------------------+----------+----------+-------------+ | |||
| Age | http | standard | Section 7.1 | | | Age | http | standard | Section 7.1 | | |||
| Cache-Control | http | standard | Section 7.2 | | | Cache-Control | http | standard | Section 7.2 | | |||
| Expires | http | standard | Section 7.3 | | | Expires | http | standard | Section 7.3 | | |||
| Pragma | http | standard | Section 7.4 | | | Pragma | http | standard | Section 7.4 | | |||
| Warning | http | standard | Section 7.5 | | | Warning | http | standard | Section 7.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". | |||
10. Security Considerations | 10. Security Considerations | |||
This section is meant to inform developers, information providers, | ||||
and users of known security concerns specific to HTTP/1.1 caching. | ||||
More general security considerations are addressed in HTTP messaging | ||||
[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 | ||||
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. | ||||
Implementation flaws might allow attackers to insert content into a | Implementation flaws might allow attackers to insert content into a | |||
cache ("cache poisoning"), leading to compromise of clients that | cache ("cache poisoning"), leading to compromise of clients that | |||
trust that content. Because of their nature, these attacks are | trust that content. Because of their nature, these attacks are | |||
difficult to mitigate. | 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 unauthorised parties. | it to unauthorized parties. | |||
Note that the Set-Cookie response header [RFC6265] does not inhibit | Note that the Set-Cookie response header [RFC6265] does not inhibit | |||
caching; a cacheable response with a Set-Cookie header can be (and | caching; a cacheable response with a Set-Cookie header can be (and | |||
often is) used to satisfy subsequent requests to caches. Servers who | often is) used to satisfy subsequent requests to caches. Servers who | |||
wish to control caching of these responses are encouraged to emit | wish to control caching of these responses are encouraged to emit | |||
appropriate Cache-Control response headers. | appropriate Cache-Control response headers. | |||
11. Acknowledgments | 11. Acknowledgments | |||
See Section 9 of [Part1]. | See Section 9 of [Part1]. | |||
12. References | 12. References | |||
12.1. Normative References | 12.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-21 (work in progress), | draft-ietf-httpbis-p1-messaging-22 (work in progress), | |||
October 2012. | February 2013. | |||
[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-21 (work in progress), | draft-ietf-httpbis-p2-semantics-22 (work in progress), | |||
October 2012. | February 2013. | |||
[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-21 (work in progress), | draft-ietf-httpbis-p4-conditional-22 (work in progress), | |||
October 2012. | February 2013. | |||
[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-21 (work in progress), | draft-ietf-httpbis-p5-range-22 (work in progress), | |||
October 2012. | February 2013. | |||
[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-21 (work in progress), | draft-ietf-httpbis-p7-auth-22 (work in progress), | |||
October 2012. | February 2013. | |||
[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. | |||
12.2. Informative References | 12.2. Informative References | |||
[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration | ||||
Procedures for Message Header Fields", BCP 90, RFC 3864, | ||||
September 2004. | ||||
[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 | ||||
Procedures for Message Header Fields", BCP 90, RFC 3864, | ||||
September 2004. | ||||
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an | [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an | |||
IANA Considerations Section in RFCs", BCP 26, RFC 5226, | IANA Considerations Section in RFCs", BCP 26, RFC 5226, | |||
May 2008. | May 2008. | |||
[RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale | [RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale | |||
Content", RFC 5861, April 2010. | Content", RFC 5861, April 2010. | |||
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, | [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, | |||
April 2011. | April 2011. | |||
Appendix A. Changes from RFC 2616 | Appendix A. Changes from RFC 2616 | |||
Make the specified age calculation algorithm less conservative. | Caching-related text has been substantially rewritten for clarity. | |||
The algorithm for calculating age is now less conservative. | ||||
(Section 4.1.3) | (Section 4.1.3) | |||
Remove requirement to consider "Content-Location" in successful | Caches are now required to handle dates with timezones as if they're | |||
responses in order to determine the appropriate response to use. | invalid, because it's not possible to accurately guess. | |||
(Section 4.1.3) | ||||
The Content-Location response header field is no longer used to | ||||
determine the appropriate response to use when validating. | ||||
(Section 4.2) | (Section 4.2) | |||
The algorithm for selecting a cached negotiated response to use has | ||||
been clarified in several ways. In particular, it now explicitly | ||||
allows header-specific canonicalization when processing selecting | ||||
header fields. (Section 4.3) | ||||
Clarify denial of service attack avoidance requirement. (Section 6) | Requirements regarding denial of service attack avoidance when | |||
performing invalidation have been clarified. (Section 6) | ||||
Do not mention RFC 2047 encoding and multiple languages in "Warning" | Cache invalidation only occurs when a successful response is | |||
header fields anymore, as these aspects never were implemented. | received. (Section 6) | |||
The conditions under which an authenticated response can be cached | ||||
have been clarified. (Section 3.2) | ||||
The one-year limit on Expires header field values has been removed; | ||||
instead, the reasoning for using a sensible value is given. | ||||
(Section 7.3) | ||||
The Pragma header field is now only defined for backwards | ||||
compatibility; future pragmas are deprecated. (Section 7.4) | ||||
Cache directives are explicitly defined to be case-insensitive. | ||||
(Section 7.2) | ||||
Handling of multiple instances of cache directives when only one is | ||||
expected is now defined. (Section 7.2) | ||||
The qualified forms of the private and no-cache cache directives are | ||||
noted to not be widely implemented; e.g., "private=foo" is | ||||
interpreted by many caches as simply "private". Additionally, the | ||||
meaning of the qualified form of no-cache has been clarified. | ||||
(Section 7.2.2) | ||||
The "no-store" cache request directive doesn't apply to responses; | ||||
i.e., a cache can satisfy a request with no-store on it, and does not | ||||
invalidate it. (Section 7.2.1.2) | ||||
The "no-cache" response cache directive's meaning has been clarified. | ||||
(Section 7.2.2.3) | ||||
New status codes can now define that caches are allowed to use | ||||
heuristic freshness with them. (Section 4.1.2) | ||||
Caches are now allow to calculate heuristic freshness for URLs with | ||||
query components. (Section 4.1.2) | ||||
Some requirements regarding production of the Warning header have | ||||
been relaxed, as it is not widely implemented. (Section 7.5) | ||||
The Warning header field no longer uses RFC 2047 encoding, nor allows | ||||
multiple languages, as these aspects were not implemented. | ||||
(Section 7.5) | (Section 7.5) | |||
Introduce Cache Directive and Warn Code Registries. (Section 7.2.3 | This specification introduces the Cache Directive and Warn Code | |||
and Section 7.5.8) | Registries, and defines considerations for new cache directives. | |||
(Section 7.2.3 and Section 7.5.8) | ||||
Appendix B. Imported ABNF | Appendix B. Imported ABNF | |||
The following core rules are included by reference, as defined in | The following core rules are included by reference, as defined in | |||
Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), | Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), | |||
CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double | CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double | |||
quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any | quote), 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 | 8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII | |||
character). | character). | |||
The rules below are defined in [Part1]: | The rules below are defined in [Part1]: | |||
OWS = <OWS, defined in [Part1], Section 3.2.1> | OWS = <OWS, defined in [Part1], Section 3.2.3> | |||
field-name = <field-name, defined in [Part1], Section 3.2> | field-name = <field-name, defined in [Part1], Section 3.2> | |||
quoted-string = <quoted-string, defined in [Part1], Section 3.2.4> | quoted-string = <quoted-string, defined in [Part1], Section 3.2.6> | |||
token = <token, defined in [Part1], Section 3.2.4> | token = <token, defined in [Part1], Section 3.2.6> | |||
port = <port, defined in [Part1], Section 2.7> | port = <port, defined in [Part1], Section 2.7> | |||
pseudonym = <pseudonym, defined in [Part1], Section 5.7> | pseudonym = <pseudonym, defined in [Part1], Section 5.7.1> | |||
uri-host = <uri-host, defined in [Part1], Section 2.7> | uri-host = <uri-host, defined in [Part1], Section 2.7> | |||
The rules below are defined in other parts: | The rules below are defined in other parts: | |||
HTTP-date = <HTTP-date, defined in [Part2], Section 8.1.1.1> | HTTP-date = <HTTP-date, defined in [Part2], Section 7.1.1.1> | |||
Appendix C. Collected ABNF | Appendix C. 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.1.1.1> | HTTP-date = <HTTP-date, defined in [Part2], Section 7.1.1.1> | |||
OWS = <OWS, defined in [Part1], Section 3.2.1> | OWS = <OWS, defined in [Part1], Section 3.2.3> | |||
Pragma = *( "," OWS ) pragma-directive *( OWS "," [ OWS | Pragma = *( "," OWS ) pragma-directive *( OWS "," [ OWS | |||
pragma-directive ] ) | pragma-directive ] ) | |||
Warning = *( "," OWS ) warning-value *( OWS "," [ OWS warning-value ] | Warning = *( "," OWS ) warning-value *( OWS "," [ OWS warning-value ] | |||
) | ) | |||
cache-directive = token [ "=" ( token / quoted-string ) ] | cache-directive = token [ "=" ( token / quoted-string ) ] | |||
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 5.7> | pseudonym = <pseudonym, defined in [Part1], Section 5.7.1> | |||
quoted-string = <quoted-string, defined in [Part1], Section 3.2.4> | quoted-string = <quoted-string, defined in [Part1], Section 3.2.6> | |||
token = <token, defined in [Part1], Section 3.2.4> | token = <token, defined in [Part1], Section 3.2.6> | |||
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 39, line 8 | skipping to change at page 40, line 8 | |||
Other changes: | Other changes: | |||
o Conformance criteria and considerations regarding error handling | o Conformance criteria and considerations regarding error handling | |||
are now defined in Part 1. | are now defined in Part 1. | |||
o Move definition of "Vary" header field into Part 2. | o Move definition of "Vary" header field into Part 2. | |||
o Add security considerations with respect to cache poisoning and | o Add security considerations with respect to cache poisoning and | |||
the "Set-Cookie" header field. | the "Set-Cookie" header field. | |||
D.3. Since draft-ietf-httpbis-p6-cache-21 | ||||
Closed issues: | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/223>: "Allowing | ||||
heuristic caching for new status codes" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/406>: "304 without | ||||
validator" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/418>: "No-Transform" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/430>: "Revert prior | ||||
change to the meaning of the public cache response directive. | ||||
Index | Index | |||
1 | 1 | |||
110 Response is Stale (warn code) 30 | 110 Response is Stale (warn code) 30 | |||
111 Revalidation Failed (warn code) 30 | 111 Revalidation Failed (warn code) 30 | |||
112 Disconnected Operation (warn code) 30 | 112 Disconnected Operation (warn code) 30 | |||
113 Heuristic Expiration (warn code) 30 | 113 Heuristic Expiration (warn code) 30 | |||
199 Miscellaneous Warning (warn code) 30 | 199 Miscellaneous Warning (warn code) 31 | |||
2 | 2 | |||
214 Transformation Applied (warn code) 30 | 214 Transformation Applied (warn code) 31 | |||
299 Miscellaneous Persistent Warning (warn code) 31 | 299 Miscellaneous Persistent Warning (warn code) 31 | |||
A | A | |||
age 5 | age 5 | |||
Age header field 19 | Age header field 19 | |||
C | C | |||
cache 4 | cache 4 | |||
cache entry 6 | cache entry 6 | |||
cache key 6 | cache key 6 | |||
skipping to change at page 40, line 20 | skipping to change at page 41, line 35 | |||
heuristic expiration time 5 | heuristic expiration time 5 | |||
M | M | |||
max-age (cache directive) 21, 25 | max-age (cache directive) 21, 25 | |||
max-stale (cache directive) 21 | max-stale (cache directive) 21 | |||
min-fresh (cache directive) 22 | min-fresh (cache directive) 22 | |||
must-revalidate (cache directive) 24 | must-revalidate (cache directive) 24 | |||
N | N | |||
no-cache (cache directive) 20, 23 | no-cache (cache directive) 20, 23 | |||
no-store (cache directive) 20, 24 | no-store (cache directive) 21, 24 | |||
no-transform (cache directive) 22, 25 | no-transform (cache directive) 22, 25 | |||
O | O | |||
only-if-cached (cache directive) 22 | only-if-cached (cache directive) 22 | |||
P | P | |||
Pragma header field 28 | Pragma header field 28 | |||
private (cache directive) 22 | private (cache directive) 23 | |||
private cache 4 | private cache 4 | |||
proxy-revalidate (cache directive) 24 | proxy-revalidate (cache directive) 25 | |||
public (cache directive) 22 | public (cache directive) 22 | |||
S | S | |||
s-maxage (cache directive) 25 | s-maxage (cache directive) 25 | |||
shared cache 4 | shared cache 4 | |||
stale 5 | stale 5 | |||
strong validator 6 | strong validator 6 | |||
V | V | |||
validator 5 | validator 5 | |||
strong 6 | strong 6 | |||
W | W | |||
Warning header field 28 | Warning header field 29 | |||
Authors' Addresses | Authors' Addresses | |||
Roy T. Fielding (editor) | Roy T. Fielding (editor) | |||
Adobe Systems Incorporated | Adobe Systems Incorporated | |||
345 Park Ave | 345 Park Ave | |||
San Jose, CA 95110 | San Jose, CA 95110 | |||
USA | USA | |||
EMail: fielding@gbiv.com | EMail: fielding@gbiv.com | |||
End of changes. 97 change blocks. | ||||
181 lines changed or deleted | 264 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/ |