| draft-ietf-httpbis-p6-cache-20.txt |  | draft-ietf-httpbis-p6-cache-21.txt |
--- | --- | --- | --- | ---
| HTTPbis Working Group R. Fielding, Ed. |  | HTTPbis Working Group R. Fielding, Ed. |
| Internet-Draft Adobe |  | Internet-Draft Adobe |
| Obsoletes: 2616 (if approved) Y. Lafon, Ed. |  | Obsoletes: 2616 (if approved) M. Nottingham, Ed. |
| Intended status: Standards Track W3C |  | Intended status: Standards Track Akamai |
| Expires: January 17, 2013 M. Nottingham, Ed. |  | Expires: April 7, 2013 J. Reschke, Ed. |
| Rackspace |  |  |
| J. Reschke, Ed. |  |  |
| greenbytes |  | greenbytes |
| July 16, 2012 |  | October 4, 2012 |
| HTTP/1.1, part 6: Caching |  | Hypertext Transfer Protocol (HTTP/1.1): Caching |
| draft-ietf-httpbis-p6-cache-20 |  | draft-ietf-httpbis-p6-cache-21 |
| 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.1. |  | The changes in this draft are summarized in Appendix D.2. |
| Status of This Memo |  | Status of This Memo |
| This Internet-Draft is submitted in full conformance with the |  | This Internet-Draft is submitted in full conformance with the |
| provisions of BCP 78 and BCP 79. |  | provisions of BCP 78 and BCP 79. |
| Internet-Drafts are working documents of the Internet Engineering |  | Internet-Drafts are working documents of the Internet Engineering |
| Task Force (IETF). Note that other groups may also distribute |  | Task Force (IETF). Note that other groups may also distribute |
| working documents as Internet-Drafts. The list of current Internet- |  | working documents as Internet-Drafts. The list of current Internet- |
| Drafts is at http://datatracker.ietf.org/drafts/current/. |  | Drafts is at http://datatracker.ietf.org/drafts/current/. |
| Internet-Drafts are draft documents valid for a maximum of six months |  | Internet-Drafts are draft documents valid for a maximum of six months |
| and may be updated, replaced, or obsoleted by other documents at any |  | and may be updated, replaced, or obsoleted by other documents at any |
| time. It is inappropriate to use Internet-Drafts as reference |  | time. It is inappropriate to use Internet-Drafts as reference |
| material or to cite them other than as "work in progress." |  | material or to cite them other than as "work in progress." |
|  |  | This Internet-Draft will expire on April 7, 2013. |
| This Internet-Draft will expire on January 17, 2013. |  |  |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2012 IETF Trust and the persons identified as the |  | Copyright (c) 2012 IETF Trust and the persons identified as the |
| document authors. All rights reserved. |  | document authors. All rights reserved. |
| This document is subject to BCP 78 and the IETF Trust's Legal |  | This document is subject to BCP 78 and the IETF Trust's Legal |
| Provisions Relating to IETF Documents |  | Provisions Relating to IETF Documents |
| (http://trustee.ietf.org/license-info) in effect on the date of |  | (http://trustee.ietf.org/license-info) in effect on the date of |
| publication of this document. Please review these documents |  | publication of this document. Please review these documents |
| skipping to change at page 2, line 41 |  | skipping to change at page 2, line 39 |
| not be created outside the IETF Standards Process, except to format |  | not be created outside the IETF Standards Process, except to format |
| it for publication as an RFC or to translate it into languages other |  | it for publication as an RFC or to translate it into languages other |
| than English. |  | than English. |
| Table of Contents |  | Table of Contents |
| 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 . . . . . . . . . . . . . . . . . . . . . 7 |  | 1.4. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 |
| 1.4.1. Delta Seconds . . . . . . . . . . . . . . . . . . . . 7 |  | 1.4.1. Delta Seconds . . . . . . . . . . . . . . . . . . . . 6 |
| 2. Overview of Cache Operation . . . . . . . . . . . . . . . . . 7 |  | 2. Overview of Cache Operation . . . . . . . . . . . . . . . . . 6 |
| 3. Storing Responses in Caches . . . . . . . . . . . . . . . . . 8 |  | 3. Storing Responses in Caches . . . . . . . . . . . . . . . . . 7 |
| 3.1. Storing Incomplete Responses . . . . . . . . . . . . . . . 9 |  | 3.1. Storing Incomplete Responses . . . . . . . . . . . . . . . 8 |
| 3.2. Storing Responses to Authenticated Requests . . . . . . . 9 |  | 3.2. Storing Responses to Authenticated Requests . . . . . . . 8 |
| 4. Constructing Responses from Caches . . . . . . . . . . . . . . 10 |  | 4. Constructing Responses from Caches . . . . . . . . . . . . . . 9 |
| 4.1. Freshness Model . . . . . . . . . . . . . . . . . . . . . 11 |  | 4.1. Freshness Model . . . . . . . . . . . . . . . . . . . . . 10 |
| 4.1.1. Calculating Freshness Lifetime . . . . . . . . . . . . 12 |  | 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 . . . . . . . . . . . . . . . . . . . 13 |  | 4.1.3. Calculating Age . . . . . . . . . . . . . . . . . . . 12 |
| 4.1.4. Serving Stale Responses . . . . . . . . . . . . . . . 15 |  | 4.1.4. Serving Stale Responses . . . . . . . . . . . . . . . 14 |
| 4.2. Validation Model . . . . . . . . . . . . . . . . . . . . . 16 |  | 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 . . . . . . . . . . . . . . . . 17 |  | 4.3. Using Negotiated Responses . . . . . . . . . . . . . . . . 16 |
| 4.4. Combining Partial Content . . . . . . . . . . . . . . . . 18 |  | 4.4. Combining Partial Content . . . . . . . . . . . . . . . . 17 |
| 5. Updating Caches with HEAD Responses . . . . . . . . . . . . . 19 |  | 5. Updating Caches with HEAD Responses . . . . . . . . . . . . . 18 |
| 6. Request Methods that Invalidate . . . . . . . . . . . . . . . 19 |  | 6. Request Methods that Invalidate . . . . . . . . . . . . . . . 18 |
| 7. Header Field Definitions . . . . . . . . . . . . . . . . . . . 20 |  | 7. Header Field Definitions . . . . . . . . . . . . . . . . . . . 19 |
| 7.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 |  | 7.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 |
| 7.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 20 |  | 7.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 20 |
| 7.2.1. Request Cache-Control Directives . . . . . . . . . . . 21 |  | 7.2.1. Request Cache-Control Directives . . . . . . . . . . . 20 |
| 7.2.2. Response Cache-Control Directives . . . . . . . . . . 23 |  | 7.2.2. Response Cache-Control Directives . . . . . . . . . . 22 |
| 7.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 26 |  | 7.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 25 |
| 7.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 28 |  | 7.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 27 |
| 7.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 28 |  | 7.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 28 |
| 7.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 |  | 7.5. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 28 |
| 7.6. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 30 |  | 7.5.1. 110 Response is Stale . . . . . . . . . . . . . . . . 30 |
| 7.6.1. 110 Response is Stale . . . . . . . . . . . . . . . . 31 |  | 7.5.2. 111 Revalidation Failed . . . . . . . . . . . . . . . 30 |
| 7.6.2. 111 Revalidation Failed . . . . . . . . . . . . . . . 32 |  | 7.5.3. 112 Disconnected Operation . . . . . . . . . . . . . . 30 |
| 7.6.3. 112 Disconnected Operation . . . . . . . . . . . . . . 32 |  | 7.5.4. 113 Heuristic Expiration . . . . . . . . . . . . . . . 30 |
| 7.6.4. 113 Heuristic Expiration . . . . . . . . . . . . . . . 32 |  | 7.5.5. 199 Miscellaneous Warning . . . . . . . . . . . . . . 30 |
| 7.6.5. 199 Miscellaneous Warning . . . . . . . . . . . . . . 32 |  | 7.5.6. 214 Transformation Applied . . . . . . . . . . . . . . 30 |
| 7.6.6. 214 Transformation Applied . . . . . . . . . . . . . . 32 |  | 7.5.7. 299 Miscellaneous Persistent Warning . . . . . . . . . 31 |
| 7.6.7. 299 Miscellaneous Persistent Warning . . . . . . . . . 32 |  | 7.5.8. Warn Code Extensions . . . . . . . . . . . . . . . . . 31 |
| 7.6.8. Warn Code Extensions . . . . . . . . . . . . . . . . . 32 |  | 8. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 31 |
| 8. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 33 |  | 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 |
| 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 |  | 9.1. Cache Directive Registry . . . . . . . . . . . . . . . . . 31 |
| 9.1. Cache Directive Registry . . . . . . . . . . . . . . . . . 33 |  | 9.2. Warn Code Registry . . . . . . . . . . . . . . . . . . . . 32 |
| 9.2. Warn Code Registry . . . . . . . . . . . . . . . . . . . . 34 |  | 9.3. Header Field Registration . . . . . . . . . . . . . . . . 33 |
| 9.3. Header Field Registration . . . . . . . . . . . . . . . . 34 |  | 10. Security Considerations . . . . . . . . . . . . . . . . . . . 33 |
| 10. Security Considerations . . . . . . . . . . . . . . . . . . . 35 |  | 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 |
| 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 |  | 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 |
| 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 |  | 12.1. Normative References . . . . . . . . . . . . . . . . . . . 34 |
| 12.1. Normative References . . . . . . . . . . . . . . . . . . . 35 |  | 12.2. Informative References . . . . . . . . . . . . . . . . . . 34 |
| 12.2. Informative References . . . . . . . . . . . . . . . . . . 36 |  | Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 35 |
| Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 36 |  | 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) . . . . . . . . . . . . . . . . . . . . 39 |  | publication) . . . . . . . . . . . . . . . . . . . . 38 |
| D.1. Since draft-ietf-httpbis-p6-cache-19 . . . . . . . . . . . 39 |  | D.1. Since draft-ietf-httpbis-p6-cache-19 . . . . . . . . . . . 38 |
|  |  | D.2. Since draft-ietf-httpbis-p6-cache-20 . . . . . . . . . . . 38 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 |
| 1. Introduction |  | 1. Introduction |
| HTTP is typically used for distributed information systems, where |  | HTTP is typically used for distributed information systems, where |
| performance can be improved by the use of response caches. This |  | performance can be improved by the use of response caches. This |
| document defines aspects of HTTP/1.1 related to caching and reusing |  | document defines aspects of HTTP/1.1 related to caching and reusing |
| response messages. |  | response messages. |
| 1.1. Purpose |  | 1.1. Purpose |
| skipping to change at page 6, line 8 |  | skipping to change at page 6, line 8 |
| validator |  | validator |
| A protocol element (e.g., an entity-tag or a Last-Modified time) |  | A protocol element (e.g., an entity-tag or a Last-Modified time) |
| that is used to find out whether a stored response is an |  | that is used to find out whether a stored response is an |
| equivalent copy of a representation. See Section 2.1 of [Part4]. |  | equivalent copy of a representation. See Section 2.1 of [Part4]. |
| strong validator |  | strong validator |
| A validator that is defined by the origin server such that its |  | A validator that is defined by the origin server such that its |
| current value will change if the representation body changes; |  | current value will change if the representation data changes; |
| i.e., an entity-tag that is not marked as weak (Section 2.3 of |  | i.e., an entity-tag that is not marked as weak (Section 2.3 of |
| [Part4]) or, if no entity-tag is provided, a Last-Modified value |  | [Part4]) or, if no entity-tag is provided, a Last-Modified value |
| that is strong in the sense defined by Section 2.2.2 of [Part4]. |  | that is strong in the sense defined by Section 2.2.2 of [Part4]. |
| 1.3. Conformance and Error Handling |  | 1.3. Conformance and Error Handling |
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |  | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |  | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |
| document are to be interpreted as described in [RFC2119]. |  | document are to be interpreted as described in [RFC2119]. |
| This specification targets conformance criteria according to the role |  | Conformance criteria and considerations regarding error handling are |
| of a participant in HTTP communication. Hence, HTTP requirements are |  | defined in Section 2.5 of [Part1]. |
| placed on senders, recipients, clients, servers, user agents, |  |  |
| intermediaries, origin servers, proxies, gateways, or caches, |  |  |
| depending on what behavior is being constrained by the requirement. |  |  |
| See Section 2 of [Part1] for definitions of these terms. |  |  |
| The verb "generate" is used instead of "send" where a requirement |  |  |
| differentiates between creating a protocol element and merely |  |  |
| forwarding a received element downstream. |  |  |
| An implementation is considered conformant if it complies with all of |  |  |
| the requirements associated with the roles it partakes in HTTP. Note |  |  |
| that SHOULD-level requirements are relevant here, unless one of the |  |  |
| documented exceptions is applicable. |  |  |
| This document also uses ABNF to define valid protocol elements |  |  |
| (Section 1.4). In addition to the prose requirements placed upon |  |  |
| them, senders MUST NOT generate protocol elements that do not match |  |  |
| the grammar defined by the ABNF rules for those protocol elements |  |  |
| that are applicable to the sender's role. If a received protocol |  |  |
| element is processed, the recipient MUST be able to parse any value |  |  |
| that would match the ABNF rules for that protocol element, excluding |  |  |
| only those rules not applicable to the recipient's role. |  |  |
| Unless noted otherwise, a recipient MAY attempt to recover a usable |  |  |
| protocol element from an invalid construct. HTTP does not define |  |  |
| specific error handling mechanisms except when they have a direct |  |  |
| impact on security, since different applications of the protocol |  |  |
| require different error handling strategies. For example, a Web |  |  |
| browser might wish to transparently recover from a response where the |  |  |
| Location header field doesn't parse according to the ABNF, whereas a |  |  |
| systems control client might consider any form of error recovery to |  |  |
| be dangerous. |  |  |
| 1.4. Syntax Notation |  | 1.4. Syntax Notation |
| This specification uses the Augmented Backus-Naur Form (ABNF) |  | This specification uses the Augmented Backus-Naur Form (ABNF) |
| notation of [RFC5234] with the list rule extension defined in Section |  | notation of [RFC5234] with the list rule extension defined in Section |
| 1.2 of [Part1]. Appendix B describes rules imported from other |  | 1.2 of [Part1]. Appendix B describes rules imported from other |
| documents. Appendix C shows the collected ABNF with the list rule |  | documents. Appendix C shows the collected ABNF with the list rule |
| expanded. |  | expanded. |
| 1.4.1. Delta Seconds |  | 1.4.1. Delta Seconds |
| skipping to change at page 10, line 45 |  | skipping to change at page 10, line 11 |
| 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 include a single Age header field |
| (Section 7.1) in the response with a value equal to the stored |  | (Section 7.1) in the response with a value equal to the stored |
| response's current_age; see Section 4.1.3. |  | response's 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 2.1.1 of [Part2]) to the origin server; i.e., a cache is not |  | (Section 5.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. |
| skipping to change at page 12, line 41 |  | skipping to change at page 12, line 9 |
| 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 |  | If no explicit expiration time is present in a stored response that |
| has a status code whose definition allows heuristic freshness to be |  | has a status code whose definition allows heuristic freshness to be |
| used (including the following in Section 4 of [Part2]: 200 (OK), 203 |  | used (including the following in Section 7 of [Part2]: 200 (OK), 203 |
| (Non-Authoritative Information), 206 (Partial Content), 300 (Multiple |  | (Non-Authoritative Information), 206 (Partial Content), 300 (Multiple |
| Choices), 301 (Moved Permanently) and 410 (Gone)), a cache MAY |  | Choices), 301 (Moved Permanently) and 410 (Gone)), a cache MAY |
| calculate a heuristic expiration time. A cache MUST NOT use |  | calculate a heuristic expiration time. A cache MUST NOT use |
| heuristics to determine freshness for responses with status codes |  | heuristics to determine freshness for responses with status codes |
| that do not explicitly allow it. |  | that do not explicitly allow it. |
| 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. |
| skipping to change at page 13, line 41 |  | skipping to change at page 13, line 11 |
| 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 |  | HTTP/1.1 requires origin servers to send a Date header field, if |
| possible, with every response, giving the time at which the |  | possible, with every response, giving the time at which the |
| response was generated. The term "date_value" denotes the value |  | response was generated. The term "date_value" denotes the value |
| of the Date header field, in a form appropriate for arithmetic |  | of the Date header field, in a form appropriate for arithmetic |
| operations. See Section 9.10 of [Part2] for the definition of the |  | operations. See Section 8.1.1.2 of [Part2] for the definition of |
| Date header field, and for requirements regarding responses |  | the Date header field, and for requirements regarding responses |
| without it. |  | without it. |
| now |  | now |
| The term "now" means "the current value of the clock at the host |  | The term "now" means "the current value of the clock at the host |
| performing the calculation". A cache SHOULD use NTP ([RFC1305]) |  | performing the calculation". A cache SHOULD use NTP ([RFC1305]) |
| or some similar protocol to synchronize its clocks to a globally |  | or some similar protocol to synchronize its clocks to a globally |
| accurate time standard. |  | accurate time standard. |
| request_time |  | request_time |
| skipping to change at page 15, line 5 |  | 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 HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date |  | o Recipients SHOULD assume that an RFC-850 date which appears to be |
| which appears to be more than 50 years in the future is in fact in |  | more than 50 years in the future is in fact in the past (this |
| the past (this helps solve the "year 2000" problem). |  | 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- |  | recipients SHOULD match day, week and timezone names case- |
| insensitively. |  | insensitively. |
| o An HTTP/1.1 implementation MAY internally represent a parsed |  | o An implementation MAY internally represent a parsed Expires date |
| Expires date as earlier than the proper value, but MUST NOT |  | as earlier than the proper value, but MUST NOT internally |
| internally represent a parsed Expires date as later than the |  | represent a parsed Expires date as later than the proper value. |
| proper value. |  |  |
| o All expiration-related calculations MUST be done in GMT. The |  | o Recipients MUST perform all expiration-related calculations in |
| local time zone MUST NOT influence the calculation or comparison |  | GMT. The local time zone MUST NOT influence the calculation or |
| of an age or expiration time. |  | comparison of an age or expiration time. |
| o If an HTTP header field incorrectly carries a date value with a |  | o Caches SHOULD consider dates with time zones other than "GMT" |
| time zone other than GMT, it MUST be converted into GMT using the |  | invalid. |
| most conservative possible conversion. |  |  |
| 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 return 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 return 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.6) 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 |
| the requesting client, and the received response is no longer fresh, |  | the requesting client, and the received response is no longer fresh, |
| the cache can forward it to the requesting client without adding a |  | the cache can forward it to the requesting client without adding a |
| new Warning (but without removing any existing Warning header |  | new Warning (but without removing any existing Warning header |
| fields). A cache shouldn't attempt to validate a response simply |  | fields). A cache shouldn't attempt to validate a response simply |
| because that response became stale in transit. |  | because that response became stale in transit. |
| skipping to change at page 16, line 34 |  | skipping to change at page 15, line 50 |
| responses contains only partial content, the cache shouldn't include |  | responses contains only partial content, the cache shouldn't include |
| its entity-tag in the If-None-Match header field unless the request |  | its entity-tag in the If-None-Match header field unless the request |
| is for a range that would be fully satisfied by that stored response. |  | is for a range that would be fully satisfied by that stored response. |
| Cache handling of a response to a conditional request is dependent |  | Cache handling of a response to a conditional request is dependent |
| upon its status code: |  | upon its status code: |
| o A 304 (Not Modified) response status code indicates that the |  | o A 304 (Not Modified) response status code indicates that the |
| 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 response 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 return a previously stored |
| response (see Section 4.1.4). |  | response (see Section 4.1.4). |
| skipping to change at page 17, line 23 |  | skipping to change at page 16, line 38 |
| 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, there |
| is only one stored response, and that stored response also lacks a |  | is only one stored response, and that stored response also lacks a |
| validator, then that stored response is selected. |  | 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.6); |  | 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 7.5), it MUST NOT use |  | response that has a Vary header field (Section 8.2.1 of [Part2]), it |
| that response unless all of the selecting header fields nominated by |  | MUST NOT use that response unless all of the selecting header fields |
| the Vary header field match in both the original request (i.e., that |  | nominated by the Vary header field match in both the original request |
| associated with the stored response), and the presented request. |  | (i.e., that associated with the stored response), and the presented |
|  |  | request. |
| The selecting header fields from two requests are defined to match if |  | The selecting header fields from two requests are defined to match if |
| and only if those in the first request can be transformed to those in |  | and only if those in the first request can be transformed to those in |
| the second request by applying any of the following: |  | the second request by applying any of the following: |
| o adding or removing whitespace, where allowed in the header field's |  | o adding or removing whitespace, where allowed in the header field's |
| syntax |  | syntax |
| o combining multiple header fields with the same field name (see |  | o combining multiple header fields with the same field name (see |
| Section 3.2 of [Part1]) |  | Section 3.2 of [Part1]) |
| skipping to change at page 18, line 41 |  | skipping to change at page 18, line 10 |
| 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.2 of [Part5]. |
| When combining the new response with one or more stored responses, a |  | When combining the new response with one or more stored responses, a |
| cache MUST: |  | cache MUST: |
| o delete any Warning header fields in the stored response with warn- |  | o delete any Warning header fields in the stored response with warn- |
| code 1xx (see Section 7.6); |  | 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 new response, aside from |  | o use other header fields provided in the new response, aside from |
| Content-Range, to replace all instances of the corresponding |  | Content-Range, to replace all instances of the corresponding |
| header fields in the stored response. |  | header fields in the stored response. |
| 5. Updating Caches with HEAD Responses |  | 5. Updating Caches with HEAD Responses |
| skipping to change at page 19, line 24 |  | skipping to change at page 18, line 38 |
| Last-Modified value of a HEAD response differs from that in a |  | Last-Modified value of a HEAD response differs from that in a |
| selected GET response, the cache MUST consider that selected response |  | selected GET response, the cache MUST consider that selected response |
| to be stale. |  | to be stale. |
| If the Content-Length, ETag and Last-Modified values of a HEAD |  | If the Content-Length, ETag and Last-Modified values of a HEAD |
| response (when present) are the same as that in a selected GET |  | response (when present) are the same as that in a selected GET |
| response (as per Section 4.3), the cache SHOULD update the remaining |  | response (as per Section 4.3), the cache SHOULD update the remaining |
| header fields in the stored response using the following rules: |  | header fields in the stored response using the following rules: |
| 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.6); |  | 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 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 2.1.1 of [Part2]) such as |  | Because unsafe request methods (Section 5.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 28, line 16 |  | skipping to change at page 27, line 26 |
| 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 field-value is an absolute date and time as defined by HTTP-date |
| in Section 5.1 of [Part2]; a sender MUST use the rfc1123-date format. |  | in Section 8.1.1.1 of [Part2]; a sender MUST use the rfc1123-date |
|  |  | 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 MUST treat other invalid date formats, especially including |
| the value "0", as in the past (i.e., "already expired"). |  | the value "0", as in the past (i.e., "already expired"). |
| skipping to change at page 29, line 35 |  | skipping to change at page 28, line 46 |
| Pragma: no-cache |  | Pragma: no-cache |
| will constrain HTTP/1.1 caches to serve a response no older than 30 |  | will constrain HTTP/1.1 caches to serve a response no older than 30 |
| seconds, while precluding implementations that do not understand |  | seconds, while precluding implementations that do not understand |
| Cache-Control from serving a cached response. |  | Cache-Control from serving a cached response. |
| Note: Because the meaning of "Pragma: no-cache" in responses is |  | Note: Because the meaning of "Pragma: no-cache" in responses is |
| not specified, it does not provide a reliable replacement for |  | not specified, it does not provide a reliable replacement for |
| "Cache-Control: no-cache" in them. |  | "Cache-Control: no-cache" in them. |
| 7.5. Vary |  | 7.5. Warning |
| The "Vary" header field conveys the set of header fields that were |  |  |
| used to select the representation. |  |  |
| Caches use this information, in part, to determine whether a stored |  |  |
| response can be used to satisfy a given request; see Section 4.3. |  |  |
| In uncacheable or stale responses, the Vary field value advises the |  |  |
| user agent about the criteria that were used to select the |  |  |
| representation. |  |  |
| Vary = "*" / 1#field-name |  |  |
| The set of header fields named by the Vary field value is known as |  |  |
| the selecting header fields. |  |  |
| A server SHOULD include a Vary header field with any cacheable |  |  |
| response that is subject to server-driven negotiation. Doing so |  |  |
| allows a cache to properly interpret future requests on that resource |  |  |
| and informs the user agent about the presence of negotiation on that |  |  |
| resource. A server MAY include a Vary header field with a non- |  |  |
| cacheable response that is subject to server-driven negotiation, |  |  |
| since this might provide the user agent with useful information about |  |  |
| the dimensions over which the response varies at the time of the |  |  |
| response. |  |  |
| A Vary field value of "*" signals that unspecified parameters not |  |  |
| limited to the header fields (e.g., the network address of the |  |  |
| client), play a role in the selection of the response representation; |  |  |
| therefore, a cache cannot determine whether this response is |  |  |
| appropriate. A proxy MUST NOT generate the "*" value. |  |  |
| The field-names given are not limited to the set of standard header |  |  |
| fields defined by this specification. Field names are case- |  |  |
| insensitive. |  |  |
| 7.6. Warning |  |  |
| The "Warning" header field is used to carry additional information |  | The "Warning" header field is used to carry additional information |
| about the status or transformation of a message that might not be |  | about the status or transformation of a message that might not be |
| reflected in the message. This information is typically used to warn |  | reflected in the message. This information is typically used to warn |
| about possible incorrectness introduced by caching operations or |  | about possible incorrectness introduced by caching operations or |
| transformations applied to the payload of the message. |  | transformations applied to the payload of the message. |
| Warnings can be used for other purposes, both cache-related and |  | Warnings can be used for other purposes, both cache-related and |
| otherwise. The use of a warning, rather than an error status code, |  | otherwise. The use of a warning, rather than an error status code, |
| distinguishes these responses from true failures. |  | distinguishes these responses from true failures. |
| skipping to change at page 31, line 47 |  | skipping to change at page 30, line 21 |
| 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.6.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 include this whenever the returned response is stale. |
| 7.6.2. 111 Revalidation Failed |  | 7.5.2. 111 Revalidation Failed |
| A cache SHOULD include this when returning a stale response because |  | A cache SHOULD include this when returning a stale response because |
| an attempt to validate the response failed, due to an inability to |  | an attempt to validate the response failed, due to an inability to |
| reach the server. |  | reach the server. |
| 7.6.3. 112 Disconnected Operation |  | 7.5.3. 112 Disconnected Operation |
| A cache SHOULD include this if it is intentionally disconnected from |  | A cache SHOULD include 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.6.4. 113 Heuristic Expiration |  | 7.5.4. 113 Heuristic Expiration |
| A cache SHOULD include this if it heuristically chose a freshness |  | A cache SHOULD include 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.6.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. |
| 7.6.6. 214 Transformation Applied |  | 7.5.6. 214 Transformation Applied |
| MUST be added by a proxy if it applies any transformation to the |  | MUST be added by a proxy if it applies any transformation to the |
| representation, such as changing the content-coding, media-type, or |  | representation, such as changing the content-coding, media-type, or |
| modifying the representation data, unless this Warning code already |  | modifying the representation data, unless this Warning code already |
| appears in the response. |  | appears in the response. |
| 7.6.7. 299 Miscellaneous Persistent Warning |  | 7.5.7. 299 Miscellaneous Persistent 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. |  | take any automated action. |
| 7.6.8. Warn Code Extensions |  | 7.5.8. Warn Code Extensions |
| The HTTP Warn Code Registry defines the name space for warn codes. |  | The HTTP Warn Code Registry defines the name space for warn codes. |
| A registration MUST include the following fields: |  | A registration MUST include the following fields: |
| o Warn Code (3 digits) |  | o Warn Code (3 digits) |
| o Short Description |  | o Short Description |
| o Pointer to specification text |  | o Pointer to specification text |
| Values to be added to this name space require IETF Review (see |  | Values to be added to this name space require IETF Review (see |
| [RFC5226], Section 4.1). |  | [RFC5226], Section 4.1). |
| The registry itself is maintained at |  | The registry itself is maintained at |
| <http://www.iana.org/assignments/http-warn-codes>. |  | <http://www.iana.org/assignments/http-warn-codes>. |
| 8. History Lists |  | 8. History Lists |
| skipping to change at page 34, line 27 |  | skipping to change at page 32, line 31 |
| | proxy-revalidate | Section 7.2.2.6 | |  | | proxy-revalidate | Section 7.2.2.6 | |
| | public | Section 7.2.2.1 | |  | | public | Section 7.2.2.1 | |
| | s-maxage | Section 7.2.2.8 | |  | | s-maxage | Section 7.2.2.8 | |
| | stale-if-error | [RFC5861], Section 4 | |  | | stale-if-error | [RFC5861], Section 4 | |
| | stale-while-revalidate | [RFC5861], Section 3 | |  | | stale-while-revalidate | [RFC5861], Section 3 | |
| +------------------------+----------------------------------+ |  | +------------------------+----------------------------------+ |
| 9.2. Warn Code Registry |  | 9.2. Warn Code Registry |
| The registration procedure for HTTP Warn Codes is defined by |  | The registration procedure for HTTP Warn Codes is defined by |
| Section 7.6.8 of this document. |  | Section 7.5.8 of this document. |
| The HTTP Warn Code Registry shall be created at |  | The HTTP Warn Code Registry shall be created at |
| <http://www.iana.org/assignments/http-cache-directives> and be |  | <http://www.iana.org/assignments/http-cache-directives> and be |
| populated with the registrations below: |  | populated with the registrations below: |
| +-----------+----------------------------------+---------------+ |  | +-----------+----------------------------------+---------------+ |
| | Warn Code | Short Description | Reference | |  | | Warn Code | Short Description | Reference | |
| +-----------+----------------------------------+---------------+ |  | +-----------+----------------------------------+---------------+ |
| | 110 | Response is Stale | Section 7.6.1 | |  | | 110 | Response is Stale | Section 7.5.1 | |
| | 111 | Revalidation Failed | Section 7.6.2 | |  | | 111 | Revalidation Failed | Section 7.5.2 | |
| | 112 | Disconnected Operation | Section 7.6.3 | |  | | 112 | Disconnected Operation | Section 7.5.3 | |
| | 113 | Heuristic Expiration | Section 7.6.4 | |  | | 113 | Heuristic Expiration | Section 7.5.4 | |
| | 199 | Miscellaneous Warning | Section 7.6.5 | |  | | 199 | Miscellaneous Warning | Section 7.5.5 | |
| | 214 | Transformation Applied | Section 7.6.6 | |  | | 214 | Transformation Applied | Section 7.5.6 | |
| | 299 | Miscellaneous Persistent Warning | Section 7.6.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 [RFC3864]): |
| +-------------------+----------+----------+-------------+ |  | +-------------------+----------+----------+-------------+ |
| | 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 | |
| | Vary | http | standard | Section 7.5 | |  | | Warning | http | standard | Section 7.5 | |
| | Warning | http | standard | Section 7.6 | |  |  |
| +-------------------+----------+----------+-------------+ |  | +-------------------+----------+----------+-------------+ |
| The change controller is: "IETF (iesg@ietf.org) - Internet |  | The change controller is: "IETF (iesg@ietf.org) - Internet |
| Engineering Task Force". |  | Engineering Task Force". |
| 10. Security Considerations |  | 10. Security Considerations |
| Caches expose additional potential vulnerabilities, since the |  | Caches expose additional potential vulnerabilities, since the |
| contents of the cache represent an attractive target for malicious |  | contents of the cache represent an attractive target for malicious |
| exploitation. Because cache contents persist after an HTTP request |  | exploitation. Because cache contents persist after an HTTP request |
| is complete, an attack on the cache can reveal information long after |  | is complete, an attack on the cache can reveal information long after |
| a user believes that the information has been removed from the |  | a user believes that the information has been removed from the |
| network. Therefore, cache contents need to be protected as sensitive |  | network. Therefore, cache contents need to be protected as sensitive |
| information. |  | information. |
|  |  | Implementation flaws might allow attackers to insert content into a |
|  |  | cache ("cache poisoning"), leading to compromise of clients that |
|  |  | trust that content. Because of their nature, these attacks are |
|  |  | difficult to mitigate. |
|  |  | Likewise, implementation flaws (as well as misunderstanding of cache |
|  |  | operation) might lead to caching of sensitive information (e.g., |
|  |  | authentication credentials) that is thought to be private, exposing |
|  |  | it to unauthorised parties. |
|  |  | Note that the Set-Cookie response header [RFC6265] does not inhibit |
|  |  | caching; a cacheable response with a Set-Cookie header can be (and |
|  |  | often is) used to satisfy subsequent requests to caches. Servers who |
|  |  | wish to control caching of these responses are encouraged to emit |
|  |  | 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., Lafon, Y., Ed., and J. Reschke, Ed., |  | [Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |
| "HTTP/1.1, part 1: Message Routing and Syntax"", |  | Protocol (HTTP/1.1): Message Syntax and Routing", |
| draft-ietf-httpbis-p1-messaging-20 (work in progress), |  | draft-ietf-httpbis-p1-messaging-21 (work in progress), |
| July 2012. |  | October 2012. |
| [Part2] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |  | [Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |
| "HTTP/1.1, part 2: Semantics and Payloads", |  | Protocol (HTTP/1.1): Semantics and Content", |
| draft-ietf-httpbis-p2-semantics-20 (work in progress), |  | draft-ietf-httpbis-p2-semantics-21 (work in progress), |
| July 2012. |  | October 2012. |
| [Part4] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |  | [Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |
| "HTTP/1.1, part 4: Conditional Requests", |  | Protocol (HTTP/1.1): Conditional Requests", |
| draft-ietf-httpbis-p4-conditional-20 (work in progress), |  | draft-ietf-httpbis-p4-conditional-21 (work in progress), |
| July 2012. |  | October 2012. |
| [Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |  | [Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |
| "HTTP/1.1, part 5: Range Requests", |  | "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", |
| draft-ietf-httpbis-p5-range-20 (work in progress), |  | draft-ietf-httpbis-p5-range-21 (work in progress), |
| July 2012. |  | October 2012. |
| [Part7] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |  | [Part7] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |
| "HTTP/1.1, part 7: Authentication", |  | Protocol (HTTP/1.1): Authentication", |
| draft-ietf-httpbis-p7-auth-20 (work in progress), |  | draft-ietf-httpbis-p7-auth-21 (work in progress), |
| July 2012. |  | October 2012. |
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |  | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |
| Requirement Levels", BCP 14, RFC 2119, March 1997. |  | Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax |  | [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax |
| Specifications: ABNF", STD 68, RFC 5234, January 2008. |  | Specifications: ABNF", STD 68, RFC 5234, January 2008. |
| 12.2. Informative References |  | 12.2. Informative References |
| [RFC1305] Mills, D., "Network Time Protocol (Version 3) |  | [RFC1305] Mills, D., "Network Time Protocol (Version 3) |
| skipping to change at page 36, line 39 |  | skipping to change at page 35, line 16 |
| Procedures for Message Header Fields", BCP 90, RFC 3864, |  | Procedures for Message Header Fields", BCP 90, RFC 3864, |
| September 2004. |  | 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, |
|  |  | April 2011. |
| Appendix A. Changes from RFC 2616 |  | Appendix A. Changes from RFC 2616 |
| Make the specified age calculation algorithm less conservative. |  | Make the specified age calculation algorithm less conservative. |
| (Section 4.1.3) |  | (Section 4.1.3) |
| Remove requirement to consider Content-Location in successful |  | Remove requirement to consider "Content-Location" in successful |
| responses in order to determine the appropriate response to use. |  | responses in order to determine the appropriate response to use. |
| (Section 4.2) |  | (Section 4.2) |
| Clarify denial of service attack avoidance requirement. (Section 6) |  | Clarify denial of service attack avoidance requirement. (Section 6) |
| Change ABNF productions for header fields to only define the field |  | Do not mention RFC 2047 encoding and multiple languages in "Warning" |
| value. (Section 7) |  |  |
| Do not mention RFC 2047 encoding and multiple languages in Warning |  |  |
| header fields anymore, as these aspects never were implemented. |  | header fields anymore, as these aspects never were implemented. |
| (Section 7.6) |  | (Section 7.5) |
| Introduce Cache Directive and Warn Code Registries. (Section 7.2.3 |  | Introduce Cache Directive and Warn Code Registries. (Section 7.2.3 |
| and Section 7.6.8) |  | 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.1> |
| 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.4> |
| token = <token, defined in [Part1], Section 3.2.4> |  | token = <token, defined in [Part1], Section 3.2.4> |
| port = <port, defined in [Part1], Section 2.8> |  | port = <port, defined in [Part1], Section 2.7> |
| pseudonym = <pseudonym, defined in [Part1], Section 6.2> |  | pseudonym = <pseudonym, defined in [Part1], Section 5.7> |
| uri-host = <uri-host, defined in [Part1], Section 2.8> |  | 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 5.1> |  | HTTP-date = <HTTP-date, defined in [Part2], Section 8.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 5.1> |  | HTTP-date = <HTTP-date, defined in [Part2], Section 8.1.1.1> |
| OWS = <OWS, defined in [Part1], Section 3.2.1> |  | OWS = <OWS, defined in [Part1], Section 3.2.1> |
| Pragma = *( "," OWS ) pragma-directive *( OWS "," [ OWS |  | Pragma = *( "," OWS ) pragma-directive *( OWS "," [ OWS |
| pragma-directive ] ) |  | pragma-directive ] ) |
| Vary = "*" / ( *( "," OWS ) field-name *( OWS "," [ OWS field-name ] |  |  |
| ) ) |  |  |
| 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.8> |  | 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 6.2> |  | pseudonym = <pseudonym, defined in [Part1], Section 5.7> |
| quoted-string = <quoted-string, defined in [Part1], Section 3.2.4> |  | quoted-string = <quoted-string, defined in [Part1], Section 3.2.4> |
| token = <token, defined in [Part1], Section 3.2.4> |  | token = <token, defined in [Part1], Section 3.2.4> |
| uri-host = <uri-host, defined in [Part1], Section 2.8> |  | 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 |
| ] |  | ] |
| Appendix D. Change Log (to be removed by RFC Editor before publication) |  | Appendix D. Change Log (to be removed by RFC Editor before publication) |
| skipping to change at page 39, line 36 |  | skipping to change at page 38, line 36 |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/360>: "enhance |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/360>: "enhance |
| considerations for new cache control directives" |  | considerations for new cache control directives" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/361>: "ABNF |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/361>: "ABNF |
| requirements for recipients" |  | requirements for recipients" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/368>: "note |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/368>: "note |
| introduction of new IANA registries as normative changes" |  | introduction of new IANA registries as normative changes" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/373>: "broken prose |
|  |  | in description of 'Vary'" |
|  |  | D.2. Since draft-ietf-httpbis-p6-cache-20 |
|  |  | Closed issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/375>: "'Most |
|  |  | Conservative'" |
|  |  | Other changes: |
|  |  | o Conformance criteria and considerations regarding error handling |
|  |  | are now defined in Part 1. |
|  |  | o Move definition of "Vary" header field into Part 2. |
|  |  | o Add security considerations with respect to cache poisoning and |
|  |  | the "Set-Cookie" header field. |
| Index |  | Index |
| 1 |  | 1 |
| 110 Response is Stale (warn code) 31 |  | 110 Response is Stale (warn code) 30 |
| 111 Revalidation Failed (warn code) 32 |  | 111 Revalidation Failed (warn code) 30 |
| 112 Disconnected Operation (warn code) 32 |  | 112 Disconnected Operation (warn code) 30 |
| 113 Heuristic Expiration (warn code) 32 |  | 113 Heuristic Expiration (warn code) 30 |
| 199 Miscellaneous Warning (warn code) 32 |  | 199 Miscellaneous Warning (warn code) 30 |
| 2 |  | 2 |
| 214 Transformation Applied (warn code) 32 |  | 214 Transformation Applied (warn code) 30 |
| 299 Miscellaneous Persistent Warning (warn code) 32 |  | 299 Miscellaneous Persistent Warning (warn code) 31 |
| A |  | A |
| age 5 |  | age 5 |
| Age header field 20 |  | Age header field 19 |
| C |  | C |
| cache 4 |  | cache 4 |
| Cache Directives |  | cache entry 6 |
| max-age 22, 25 |  | cache key 6 |
| max-stale 22 |  |  |
| min-fresh 22 |  |  |
| must-revalidate 25 |  |  |
| no-cache 21, 24 |  |  |
| no-store 21, 25 |  |  |
| no-transform 23, 26 |  |  |
| only-if-cached 23 |  |  |
| private 23 |  |  |
| proxy-revalidate 25 |  |  |
| public 23 |  |  |
| s-maxage 26 |  |  |
| cache entry 7 |  |  |
| cache key 7 |  |  |
| Cache-Control header field 20 |  | Cache-Control header field 20 |
| cacheable 4 |  | cacheable 4 |
| E |  | E |
| Expires header field 28 |  | Expires header field 27 |
| explicit expiration time 5 |  | explicit expiration time 5 |
| F |  | F |
| first-hand 5 |  | first-hand 5 |
| fresh 5 |  | fresh 5 |
| freshness lifetime 5 |  | freshness lifetime 5 |
| G |  | G |
| Grammar |  | Grammar |
| Age 20 |  | Age 19 |
| Cache-Control 21 |  |  |
| cache-directive 21 |  |  |
| delta-seconds 7 |  |  |
| Expires 28 |  |  |
| extension-pragma 29 |  |  |
| Pragma 29 |  |  |
| pragma-directive 29 |  |  |
| Vary 29 |  |  |
| warn-agent 30 |  |  |
| warn-code 30 |  |  |
| warn-date 30 |  |  |
| warn-text 30 |  |  |
| Warning 30 |  |  |
| warning-value 30 |  |  |
| H |  |  |
| Header Fields |  |  |
| Age 20 |  |  |
| Cache-Control 20 |  | Cache-Control 20 |
| Expires 28 |  | cache-directive 20 |
|  |  | delta-seconds 6 |
|  |  | Expires 27 |
|  |  | extension-pragma 28 |
| Pragma 28 |  | Pragma 28 |
| Vary 29 |  | pragma-directive 28 |
| Warning 30 |  | warn-agent 29 |
|  |  | warn-code 29 |
|  |  | warn-date 29 |
|  |  | warn-text 29 |
|  |  | Warning 29 |
|  |  | warning-value 29 |
|  |  | H |
| heuristic expiration time 5 |  | heuristic expiration time 5 |
| M |  | M |
| max-age |  | max-age (cache directive) 21, 25 |
| Cache Directive 22, 25 |  | max-stale (cache directive) 21 |
| max-stale |  | min-fresh (cache directive) 22 |
| Cache Directive 22 |  | must-revalidate (cache directive) 24 |
| min-fresh |  |  |
| Cache Directive 22 |  |  |
| must-revalidate |  |  |
| Cache Directive 25 |  |  |
| N |  | N |
| no-cache |  | no-cache (cache directive) 20, 23 |
| Cache Directive 21, 24 |  | no-store (cache directive) 20, 24 |
| no-store |  | no-transform (cache directive) 22, 25 |
| Cache Directive 21, 25 |  |  |
| no-transform |  |  |
| Cache Directive 23, 26 |  |  |
| O |  | O |
| only-if-cached |  | only-if-cached (cache directive) 22 |
| Cache Directive 23 |  |  |
| P |  | P |
| Pragma header field 28 |  | Pragma header field 28 |
| private |  | private (cache directive) 22 |
| Cache Directive 23 |  |  |
| private cache 4 |  | private cache 4 |
| proxy-revalidate |  | proxy-revalidate (cache directive) 24 |
| Cache Directive 25 |  | public (cache directive) 22 |
| public |  |  |
| Cache Directive 23 |  |  |
| S |  | S |
| s-maxage |  | s-maxage (cache directive) 25 |
| Cache Directive 26 |  |  |
| 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 |
| Vary header field 29 |  |  |
| W |  | W |
| Warn Codes |  | Warning header field 28 |
| 110 Response is Stale 31 |  |  |
| 111 Revalidation Failed 32 |  |  |
| 112 Disconnected Operation 32 |  |  |
| 113 Heuristic Expiration 32 |  |  |
| 199 Miscellaneous Warning 32 |  |  |
| 214 Transformation Applied 32 |  |  |
| 299 Miscellaneous Persistent Warning 32 |  |  |
| Warning header field 30 |  |  |
| Authors' Addresses |  | Authors' Addresses |
| Roy T. Fielding (editor) |  | Roy T. Fielding (editor) |
| Adobe Systems Incorporated |  | Adobe Systems Incorporated |
| 345 Park Ave |  | 345 Park Ave |
| San Jose, CA 95110 |  | San Jose, CA 95110 |
| USA |  | USA |
| EMail: fielding@gbiv.com |  | EMail: fielding@gbiv.com |
| URI: http://roy.gbiv.com/ |  | URI: http://roy.gbiv.com/ |
| Yves Lafon (editor) |  |  |
| World Wide Web Consortium |  |  |
| W3C / ERCIM |  |  |
| 2004, rte des Lucioles |  |  |
| Sophia-Antipolis, AM 06902 |  |  |
| France |  |  |
| EMail: ylafon@w3.org |  |  |
| URI: http://www.raubacapeu.net/people/yves/ |  |  |
| Mark Nottingham (editor) |  | Mark Nottingham (editor) |
| Rackspace |  | Akamai |
| EMail: mnot@mnot.net |  | EMail: mnot@mnot.net |
| URI: http://www.mnot.net/ |  | URI: http://www.mnot.net/ |
| Julian F. Reschke (editor) |  | Julian F. Reschke (editor) |
| greenbytes GmbH |  | greenbytes GmbH |
| Hafenweg 16 |  | Hafenweg 16 |
| Muenster, NW 48155 |  | Muenster, NW 48155 |
| Germany |  | Germany |
| EMail: julian.reschke@greenbytes.de |  | EMail: julian.reschke@greenbytes.de |
| URI: http://greenbytes.de/tech/webdav/ |  | URI: http://greenbytes.de/tech/webdav/ |
End of changes. 79 change blocks.
| 304 lines changed or deleted |  | 215 lines changed or added |
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/