| draft-ietf-httpbis-p6-cache-16.txt |  | draft-ietf-httpbis-p6-cache-17.txt |
--- | --- | --- | --- | ---
| HTTPbis Working Group R. Fielding, Ed. |  | HTTPbis Working Group R. Fielding, Ed. |
| Internet-Draft Adobe |  | Internet-Draft Adobe |
| Obsoletes: 2616 (if approved) J. Gettys |  | Obsoletes: 2616 (if approved) J. Gettys |
| Intended status: Standards Track Alcatel-Lucent |  | Intended status: Standards Track Alcatel-Lucent |
| Expires: February 25, 2012 J. Mogul |  | Expires: May 3, 2012 J. Mogul |
| HP |  | HP |
| H. Frystyk |  | H. Frystyk |
| Microsoft |  | Microsoft |
| L. Masinter |  | L. Masinter |
| Adobe |  | Adobe |
| P. Leach |  | P. Leach |
| Microsoft |  | Microsoft |
| T. Berners-Lee |  | T. Berners-Lee |
| W3C/MIT |  | W3C/MIT |
| Y. Lafon, Ed. |  | Y. Lafon, Ed. |
| W3C |  | W3C |
| M. Nottingham, Ed. |  | M. Nottingham, Ed. |
|  |  | Rackspace |
| J. Reschke, Ed. |  | J. Reschke, Ed. |
| greenbytes |  | greenbytes |
| August 24, 2011 |  | October 31, 2011 |
| HTTP/1.1, part 6: Caching |  | HTTP/1.1, part 6: Caching |
| draft-ietf-httpbis-p6-cache-16 |  | draft-ietf-httpbis-p6-cache-17 |
| Abstract |  | Abstract |
| The Hypertext Transfer Protocol (HTTP) is an application-level |  | The Hypertext Transfer Protocol (HTTP) is an application-level |
| protocol for distributed, collaborative, hypertext information |  | protocol for distributed, collaborative, hypertext information |
| systems. HTTP has been in use by the World Wide Web global |  | systems. HTTP has been in use by the World Wide Web global |
| information initiative since 1990. This document is Part 6 of the |  | information initiative since 1990. This document is Part 6 of the |
| seven-part specification that defines the protocol referred to as |  | seven-part specification that defines the protocol referred to as |
| "HTTP/1.1" and, taken together, obsoletes RFC 2616. |  | "HTTP/1.1" and, taken together, obsoletes RFC 2616. |
| skipping to change at page 2, line 6 |  | skipping to change at page 2, line 6 |
| Discussion of this draft should take place on the HTTPBIS working |  | Discussion of this draft should take place on the HTTPBIS working |
| group mailing list (ietf-http-wg@w3.org), which is archived at |  | group mailing list (ietf-http-wg@w3.org), which is archived at |
| <http://lists.w3.org/Archives/Public/ietf-http-wg/>. |  | <http://lists.w3.org/Archives/Public/ietf-http-wg/>. |
| The current issues list is at |  | The current issues list is at |
| <http://tools.ietf.org/wg/httpbis/trac/report/3> and related |  | <http://tools.ietf.org/wg/httpbis/trac/report/3> and related |
| documents (including fancy diffs) can be found at |  | documents (including fancy diffs) can be found at |
| <http://tools.ietf.org/wg/httpbis/>. |  | <http://tools.ietf.org/wg/httpbis/>. |
| The changes in this draft are summarized in Appendix C.17. |  | The changes in this draft are summarized in Appendix C.18. |
| 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 February 25, 2012. |  | This Internet-Draft will expire on May 3, 2012. |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2011 IETF Trust and the persons identified as the |  | Copyright (c) 2011 IETF Trust and the persons identified as the |
| document authors. All rights reserved. |  | document authors. All rights reserved. |
| This document is subject to BCP 78 and the IETF Trust's Legal |  | This document is subject to BCP 78 and the IETF Trust's Legal |
| Provisions Relating to IETF Documents |  | Provisions Relating to IETF Documents |
| (http://trustee.ietf.org/license-info) in effect on the date of |  | (http://trustee.ietf.org/license-info) in effect on the date of |
| publication of this document. Please review these documents |  | publication of this document. Please review these documents |
| skipping to change at page 3, line 10 |  | skipping to change at page 3, line 10 |
| outside the IETF Standards Process, and derivative works of it may |  | outside the IETF Standards Process, and derivative works of it may |
| 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 |  | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 |
| 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5 |  | 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5 |
| 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 |  | 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 |
| 1.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7 |  | 1.3. Conformance and Error Handling . . . . . . . . . . . . . . 7 |
| 1.4. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7 |  | 1.4. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7 |
| 1.4.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 7 |  | 1.4.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 8 |
| 1.4.2. ABNF Rules defined in other Parts of the |  | 1.4.2. ABNF Rules defined in other Parts of the |
| Specification . . . . . . . . . . . . . . . . . . . . 8 |  | Specification . . . . . . . . . . . . . . . . . . . . 8 |
| 1.5. Delta Seconds . . . . . . . . . . . . . . . . . . . . . . 8 |  | 1.5. Delta Seconds . . . . . . . . . . . . . . . . . . . . . . 8 |
| 2. Cache Operation . . . . . . . . . . . . . . . . . . . . . . . 8 |  | 2. Cache Operation . . . . . . . . . . . . . . . . . . . . . . . 8 |
| 2.1. Response Cacheability . . . . . . . . . . . . . . . . . . 9 |  | 2.1. Response Cacheability . . . . . . . . . . . . . . . . . . 9 |
| 2.2. Constructing Responses from Caches . . . . . . . . . . . . 10 |  | 2.2. Constructing Responses from Caches . . . . . . . . . . . . 10 |
| 2.3. Freshness Model . . . . . . . . . . . . . . . . . . . . . 11 |  | 2.3. Freshness Model . . . . . . . . . . . . . . . . . . . . . 11 |
| 2.3.1. Calculating Freshness Lifetime . . . . . . . . . . . . 12 |  | 2.3.1. Calculating Freshness Lifetime . . . . . . . . . . . . 12 |
| 2.3.2. Calculating Age . . . . . . . . . . . . . . . . . . . 13 |  | 2.3.2. Calculating Age . . . . . . . . . . . . . . . . . . . 13 |
| 2.3.3. Serving Stale Responses . . . . . . . . . . . . . . . 15 |  | 2.3.3. Serving Stale Responses . . . . . . . . . . . . . . . 15 |
| 2.4. Validation Model . . . . . . . . . . . . . . . . . . . . . 16 |  | 2.4. Validation Model . . . . . . . . . . . . . . . . . . . . . 16 |
| 2.5. Request Methods that Invalidate . . . . . . . . . . . . . 16 |  | 2.4.1. Freshening Responses . . . . . . . . . . . . . . . . . 17 |
| 2.6. Shared Caching of Authenticated Responses . . . . . . . . 17 |  | 2.5. Request Methods that Invalidate . . . . . . . . . . . . . 18 |
| 2.7. Caching Negotiated Responses . . . . . . . . . . . . . . . 18 |  | 2.6. Shared Caching of Authenticated Responses . . . . . . . . 18 |
| 2.8. Combining Partial Content . . . . . . . . . . . . . . . . 18 |  | 2.7. Caching Negotiated Responses . . . . . . . . . . . . . . . 19 |
| 2.9. Freshening Responses . . . . . . . . . . . . . . . . . . . 19 |  | 2.8. Combining Partial Content . . . . . . . . . . . . . . . . 20 |
| 3. Header Field Definitions . . . . . . . . . . . . . . . . . . . 20 |  | 3. Header Field Definitions . . . . . . . . . . . . . . . . . . . 20 |
| 3.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 |  | 3.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 |
| 3.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 20 |  | 3.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 21 |
| 3.2.1. Request Cache-Control Directives . . . . . . . . . . . 21 |  | 3.2.1. Request Cache-Control Directives . . . . . . . . . . . 21 |
| 3.2.2. Response Cache-Control Directives . . . . . . . . . . 23 |  | 3.2.2. Response Cache-Control Directives . . . . . . . . . . 23 |
| 3.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 25 |  | 3.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 26 |
| 3.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 26 |  | 3.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 27 |
| 3.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 27 |  | 3.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 28 |
| 3.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 |  | 3.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 |
| 3.6. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 29 |  | 3.6. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 29 |
| 4. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 31 |  | 4. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 32 |
| 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 |  | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 |
| 5.1. Cache Directive Registry . . . . . . . . . . . . . . . . . 31 |  | 5.1. Cache Directive Registry . . . . . . . . . . . . . . . . . 32 |
| 5.2. Header Field Registration . . . . . . . . . . . . . . . . 32 |  | 5.2. Header Field Registration . . . . . . . . . . . . . . . . 33 |
| 6. Security Considerations . . . . . . . . . . . . . . . . . . . 32 |  | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 33 |
| 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 |  | 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 |
| 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 |  | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 |
| 8.1. Normative References . . . . . . . . . . . . . . . . . . . 33 |  | 8.1. Normative References . . . . . . . . . . . . . . . . . . . 33 |
| 8.2. Informative References . . . . . . . . . . . . . . . . . . 33 |  | 8.2. Informative References . . . . . . . . . . . . . . . . . . 34 |
| Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 34 |  | Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 35 |
| Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 34 |  | Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 35 |
| Appendix C. Change Log (to be removed by RFC Editor before |  | Appendix C. Change Log (to be removed by RFC Editor before |
| publication) . . . . . . . . . . . . . . . . . . . . 36 |  | publication) . . . . . . . . . . . . . . . . . . . . 36 |
| C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 36 |  | C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 36 |
| C.2. Since draft-ietf-httpbis-p6-cache-00 . . . . . . . . . . . 36 |  | C.2. Since draft-ietf-httpbis-p6-cache-00 . . . . . . . . . . . 37 |
| C.3. Since draft-ietf-httpbis-p6-cache-01 . . . . . . . . . . . 37 |  | C.3. Since draft-ietf-httpbis-p6-cache-01 . . . . . . . . . . . 37 |
| C.4. Since draft-ietf-httpbis-p6-cache-02 . . . . . . . . . . . 37 |  | C.4. Since draft-ietf-httpbis-p6-cache-02 . . . . . . . . . . . 38 |
| C.5. Since draft-ietf-httpbis-p6-cache-03 . . . . . . . . . . . 37 |  | C.5. Since draft-ietf-httpbis-p6-cache-03 . . . . . . . . . . . 38 |
| C.6. Since draft-ietf-httpbis-p6-cache-04 . . . . . . . . . . . 37 |  | C.6. Since draft-ietf-httpbis-p6-cache-04 . . . . . . . . . . . 38 |
| C.7. Since draft-ietf-httpbis-p6-cache-05 . . . . . . . . . . . 38 |  | C.7. Since draft-ietf-httpbis-p6-cache-05 . . . . . . . . . . . 38 |
| C.8. Since draft-ietf-httpbis-p6-cache-06 . . . . . . . . . . . 38 |  | C.8. Since draft-ietf-httpbis-p6-cache-06 . . . . . . . . . . . 39 |
| C.9. Since draft-ietf-httpbis-p6-cache-07 . . . . . . . . . . . 38 |  | C.9. Since draft-ietf-httpbis-p6-cache-07 . . . . . . . . . . . 39 |
| C.10. Since draft-ietf-httpbis-p6-cache-08 . . . . . . . . . . . 39 |  | C.10. Since draft-ietf-httpbis-p6-cache-08 . . . . . . . . . . . 39 |
| C.11. Since draft-ietf-httpbis-p6-cache-09 . . . . . . . . . . . 39 |  | C.11. Since draft-ietf-httpbis-p6-cache-09 . . . . . . . . . . . 40 |
| C.12. Since draft-ietf-httpbis-p6-cache-10 . . . . . . . . . . . 40 |  | C.12. Since draft-ietf-httpbis-p6-cache-10 . . . . . . . . . . . 40 |
| C.13. Since draft-ietf-httpbis-p6-cache-11 . . . . . . . . . . . 40 |  | C.13. Since draft-ietf-httpbis-p6-cache-11 . . . . . . . . . . . 41 |
| C.14. Since draft-ietf-httpbis-p6-cache-12 . . . . . . . . . . . 40 |  | C.14. Since draft-ietf-httpbis-p6-cache-12 . . . . . . . . . . . 41 |
| C.15. Since draft-ietf-httpbis-p6-cache-13 . . . . . . . . . . . 40 |  | C.15. Since draft-ietf-httpbis-p6-cache-13 . . . . . . . . . . . 41 |
| C.16. Since draft-ietf-httpbis-p6-cache-14 . . . . . . . . . . . 40 |  | C.16. Since draft-ietf-httpbis-p6-cache-14 . . . . . . . . . . . 41 |
| C.17. Since draft-ietf-httpbis-p6-cache-15 . . . . . . . . . . . 41 |  | C.17. Since draft-ietf-httpbis-p6-cache-15 . . . . . . . . . . . 42 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 |  | C.18. Since draft-ietf-httpbis-p6-cache-16 . . . . . . . . . . . 42 |
|  |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 |
| 1. Introduction |  | 1. Introduction |
| HTTP is typically used for distributed information systems, where |  | HTTP is typically used for distributed information systems, where |
| performance can be improved by the use of response caches. This |  | performance can be improved by the use of response caches. This |
| document defines aspects of HTTP/1.1 related to caching and reusing |  | document defines aspects of HTTP/1.1 related to caching and reusing |
| response messages. |  | response messages. |
| 1.1. Purpose |  | 1.1. Purpose |
| skipping to change at page 7, line 13 |  | skipping to change at page 7, line 13 |
| 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 body 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. Requirements |  | 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]. |
| An implementation is not compliant if it fails to satisfy one or more |  | This document defines conformance criteria for several roles in HTTP |
| of the "MUST" or "REQUIRED" level requirements for the protocols it |  | communication, including Senders, Recipients, Clients, Servers, User- |
| implements. An implementation that satisfies all the "MUST" or |  | Agents, Origin Servers, Intermediaries, Proxies and Gateways. See |
| "REQUIRED" level and all the "SHOULD" level requirements for its |  | Section 2 of [Part1] for definitions of these terms. |
| protocols is said to be "unconditionally compliant"; one that |  |  |
| satisfies all the "MUST" level requirements but not all the "SHOULD" |  | An implementation is considered conformant if it complies with all of |
| level requirements for its protocols is said to be "conditionally |  | the requirements associated with its role(s). Note that SHOULD-level |
| compliant". |  | 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 are invalid. |
|  |  | Unless noted otherwise, Recipients MAY take steps to recover a usable |
|  |  | protocol element from an invalid construct. However, HTTP does not |
|  |  | define specific error handling mechanisms, except in cases where it |
|  |  | has direct impact on security. This is because different uses of the |
|  |  | protocol require different error handling strategies; for example, a |
|  |  | Web browser may wish to transparently recover from a response where |
|  |  | the Location header field doesn't parse according to the ABNF, |
|  |  | whereby in a systems control protocol using HTTP, this type of error |
|  |  | recovery could lead to dangerous consequences. |
| 1.4. Syntax Notation |  | 1.4. Syntax Notation |
| This specification uses the ABNF syntax defined in Section 1.2 of |  | This specification uses the ABNF syntax defined in Section 1.2 of |
| [Part1] (which extends the syntax defined in [RFC5234] with a list |  | [Part1] (which extends the syntax defined in [RFC5234] with a list |
| rule). Appendix B shows the collected ABNF, with the list rule |  | rule). Appendix B shows the collected ABNF, with the list rule |
| expanded. |  | expanded. |
| The following core rules are included by reference, as defined in |  | The following core rules are included by reference, as defined in |
| [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF |  | [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF |
| (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), |  | (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), |
| HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit |  | HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit |
| sequence of data), SP (space), VCHAR (any visible USASCII character), |  | sequence of data), SP (space), and VCHAR (any visible US-ASCII |
| and WSP (whitespace). |  | character). |
| 1.4.1. Core Rules |  | 1.4.1. Core Rules |
| The core rules below are defined in [Part1]: |  | The core rules below are defined in [Part1]: |
| OWS = <OWS, defined in [Part1], Section 1.2.2> |  | OWS = <OWS, defined in [Part1], Section 1.2.2> |
| quoted-string = <quoted-string, defined in [Part1], Section 3.2.3> |  | quoted-string = <quoted-string, defined in [Part1], Section 3.2.3> |
| token = <token, defined in [Part1], Section 3.2.3> |  | token = <token, defined in [Part1], Section 3.2.3> |
| 1.4.2. ABNF Rules defined in other Parts of the Specification |  | 1.4.2. ABNF Rules defined in other Parts of the Specification |
| The ABNF rules below are defined in other parts: |  | The ABNF rules below are defined in other parts: |
| field-name = <field-name, defined in [Part1], Section 3.2> |  | field-name = <field-name, defined in [Part1], Section 3.2> |
| HTTP-date = <HTTP-date, defined in [Part1], Section 6.1> |  | HTTP-date = <HTTP-date, defined in [Part2], Section 8> |
| port = <port, defined in [Part1], Section 2.7> |  | port = <port, defined in [Part1], Section 2.7> |
| pseudonym = <pseudonym, defined in [Part1], Section 9.9> |  | pseudonym = <pseudonym, defined in [Part1], Section 8.8> |
| uri-host = <uri-host, defined in [Part1], Section 2.7> |  | uri-host = <uri-host, defined in [Part1], Section 2.7> |
| 1.5. Delta Seconds |  | 1.5. Delta Seconds |
| The delta-seconds rule specifies a non-negative integer, representing |  | The delta-seconds rule specifies a non-negative integer, representing |
| time in seconds. |  | time in seconds. |
| delta-seconds = 1*DIGIT |  | delta-seconds = 1*DIGIT |
| If an implementation receives a delta-seconds value larger than the |  | If an implementation receives a delta-seconds value larger than the |
| largest positive integer it can represent, or if any of its |  | largest positive integer it can represent, or if any of its |
| subsequent calculations overflows, it MUST consider the value to be |  | subsequent calculations overflows, it MUST consider the value to be |
| 2147483648 (2^31). Recipients parsing a delta-seconds value SHOULD |  | 2147483648 (2^31). Recipients parsing a delta-seconds value MUST use |
| use an arithmetic type of at least 31 bits of range, and senders MUST |  | an arithmetic type of at least 31 bits of range, and senders MUST NOT |
| NOT send delta-seconds with a value greater than 2147483648. |  | send delta-seconds with a value greater than 2147483648. |
| 2. Cache Operation |  | 2. Cache Operation |
| Proper cache operation preserves the semantics of HTTP transfers |  | Proper cache operation preserves the semantics of HTTP transfers |
| ([Part2]) while eliminating the transfer of information already held |  | ([Part2]) while eliminating the transfer of information already held |
| in the cache. Although caching is an entirely OPTIONAL feature of |  | in the cache. Although caching is an entirely OPTIONAL feature of |
| HTTP, we assume that reusing the cached response is desirable and |  | HTTP, 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 |
| skipping to change at page 11, line 17 |  | skipping to change at page 11, line 31 |
| 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 3.2.3. |  | cache-control extension; see Section 3.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 3.1) in the response with a value equal to the stored |  | (Section 3.1) in the response with a value equal to the stored |
| response's current_age; see Section 2.3.2. |  | response's current_age; see Section 2.3.2. |
| A cache MUST write through requests with methods that are unsafe |  | A cache MUST write through requests with methods that are unsafe |
| (Section 7.1.1 of [Part2]) to the origin server; i.e., a cache must |  | (Section 6.1.1 of [Part2]) to the origin server; i.e., a cache must |
| not generate a reply to such a request before having forwarded the |  | not generate a reply to such a request before having forwarded the |
| request and having received a corresponding response. |  | request and having received a corresponding response. |
| Also, note that unsafe requests might invalidate already stored |  | Also, note that unsafe requests might invalidate already stored |
| responses; see Section 2.5. |  | responses; see Section 2.5. |
| 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 13, line 9 |  | skipping to change at page 13, line 22 |
| A heuristic freshness lifetime might be applicable; see |  | A heuristic freshness lifetime might be applicable; see |
| Section 2.3.1.1. |  | Section 2.3.1.1. |
| Note that this calculation is not vulnerable to clock skew, since all |  | Note that this calculation is not vulnerable to clock skew, since all |
| of the information comes from the origin server. |  | of the information comes from the origin server. |
| 2.3.1.1. Calculating Heuristic Freshness |  | 2.3.1.1. 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 8 of [Part2]: 200, 203, 206, |  | used (including the following in Section 7 of [Part2]: 200, 203, 206, |
| 300, 301 and 410), a cache MAY calculate a heuristic expiration time. |  | 300, 301 and 410), a cache MAY calculate a heuristic expiration time. |
| A cache MUST NOT use heuristics to determine freshness for responses |  | A cache MUST NOT use heuristics to determine freshness for responses |
| with status codes that do not explicitly allow it. |  | with status codes 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. |
| Also, if the response has a Last-Modified header field (Section 2.2 |  | Also, if the response has a Last-Modified header field (Section 2.2 |
| of [Part4]), a cache SHOULD NOT use a heuristic expiration value that |  | of [Part4]), caches are encouraged to use a heuristic expiration |
| is more than some fraction of the interval since that time. A |  | value that is no more than some fraction of the interval since that |
| typical setting of this fraction might be 10%. |  | time. A typical setting of this fraction might be 10%. |
| Note: RFC 2616 ([RFC2616], Section 13.9) required that caches do |  | Note: RFC 2616 ([RFC2616], Section 13.9) required that caches do |
| not calculate heuristic freshness for URIs with query components |  | not calculate heuristic freshness for URIs with query components |
| (i.e., those containing '?'). In practice, this has not been |  | (i.e., those containing '?'). In practice, this has not been |
| widely implemented. Therefore, servers are encouraged to send |  | widely implemented. Therefore, servers are encouraged to send |
| explicit directives (e.g., Cache-Control: no-cache) if they wish |  | explicit directives (e.g., Cache-Control: no-cache) if they wish |
| to preclude caching. |  | to preclude caching. |
| 2.3.2. Calculating Age |  | 2.3.2. Calculating Age |
| skipping to change at page 14, line 6 |  | skipping to change at page 14, line 19 |
| The term "age_value" denotes the value of the Age header field |  | The term "age_value" denotes the value of the Age header field |
| (Section 3.1), in a form appropriate for arithmetic operation; or |  | (Section 3.1), in a form appropriate for arithmetic operation; or |
| 0, if not available. |  | 0, if not available. |
| date_value |  | date_value |
| HTTP/1.1 requires origin servers to send a Date header field, if |  | HTTP/1.1 requires origin servers to send a Date header field, if |
| possible, with every response, giving the time at which the |  | possible, with every response, giving the time at which the |
| response was generated. The term "date_value" denotes the value |  | response was generated. The term "date_value" denotes the value |
| of the Date header field, in a form appropriate for arithmetic |  | of the Date header field, in a form appropriate for arithmetic |
| operations. See Section 9.3 of [Part1] for the definition of the |  | operations. See Section 9.2 of [Part2] for the definition of the |
| Date header field, and for requirements regarding responses |  | Date header field, and for requirements regarding responses |
| without it. |  | without it. |
| now |  | now |
| The term "now" means "the current value of the clock at the host |  | The term "now" means "the current value of the clock at the host |
| performing the calculation". A cache SHOULD use NTP ([RFC1305]) |  | performing the calculation". A cache SHOULD use NTP ([RFC1305]) |
| or some similar protocol to synchronize its clocks to a globally |  | or some similar protocol to synchronize its clocks to a globally |
| accurate time standard. |  | accurate time standard. |
| skipping to change at page 15, line 8 |  | skipping to change at page 15, line 21 |
| corrected_initial_age = max(apparent_age, corrected_age_value); |  | corrected_initial_age = max(apparent_age, corrected_age_value); |
| 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; |
| Additional rules for requirements on parsing and encoding of dates |  | Additionally, to avoid common problems in date parsing: |
| and other potential problems with date encodings include: |  |  |
| o HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date |  | o HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date |
| which appears to be more than 50 years in the future is in fact in |  | which appears to be more than 50 years in the future is in fact in |
| the past (this helps solve the "year 2000" problem). |  | 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- |  | recipients SHOULD match day, week and timezone names case- |
| insensitively. |  | insensitively. |
| o An HTTP/1.1 implementation MAY internally represent a parsed |  | o An HTTP/1.1 implementation MAY internally represent a parsed |
| skipping to change at page 15, line 44 |  | skipping to change at page 16, line 7 |
| 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 2.3. |  | according to the calculations in Section 2.3. |
| 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 3.2.2). |  | see Section 3.2.2). |
| A cache SHOULD 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 3.2.1). |  | stale request directive; see Section 3.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 3.6) to stale responses. Likewise, a cache SHOULD add |  | (see Section 3.6) 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 SHOULD 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 SHOULD NOT attempt to validate a response simply |  | fields). A cache shouldn't attempt to validate a response simply |
| because that response became stale in transit. |  | because that response became stale in transit. |
| 2.4. Validation Model |  | 2.4. Validation Model |
| When a cache has one or more stored responses for a requested URI, |  | When a cache has one or more stored responses for a requested URI, |
| but cannot serve any of them (e.g., because they are not fresh, or |  | but cannot serve any of them (e.g., because they are not fresh, or |
| one cannot be selected; see Section 2.7), it can use the conditional |  | one cannot be selected; see Section 2.7), it can use the conditional |
| request mechanism [Part4] in the forwarded request to give the origin |  | request mechanism [Part4] in the forwarded request to give the origin |
| server an opportunity to both select a valid stored response to be |  | server an opportunity to both select a valid stored response to be |
| used, and to update it. This process is known as "validating" or |  | used, and to update it. This process is known as "validating" or |
| "revalidating" the stored response. |  | "revalidating" the stored response. |
| When sending such a conditional request, a cache SHOULD add an If- |  | When sending such a conditional request, a cache adds an If-Modified- |
| Modified-Since header field whose value is that of the Last-Modified |  | Since header field whose value is that of the Last-Modified header |
| header field from the selected (see Section 2.7) stored response, if |  | field from the selected (see Section 2.7) stored response, if |
| available. |  | available. |
| Additionally, a cache SHOULD add an If-None-Match header field whose |  | Additionally, a cache can add an If-None-Match header field whose |
| value is that of the ETag header field(s) from all responses stored |  | value is that of the ETag header field(s) from all responses stored |
| for the requested URI, if present. However, if any of the stored |  | for the requested URI, if present. However, if any of the stored |
| responses contains only partial content, the cache SHOULD NOT 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. |
| A 304 (Not Modified) response status code indicates that the stored |  | Cache handling of a response to a conditional request is dependent |
| response can be updated and reused; see Section 2.9. |  | upon its status code: |
| A full response (i.e., one with a response body) indicates that none |  | o A 304 (Not Modified) response status code indicates that the |
| of the stored responses nominated in the conditional request is |  | stored response can be updated and reused; see Section 2.4.1. |
| suitable. Instead, a cache SHOULD use the full response to satisfy |  |  |
| the request and MAY replace the stored response(s). |  |  |
| If a cache receives a 5xx response while attempting to validate a |  | o A full response (i.e., one with a response body) indicates that |
| response, it MAY either forward this response to the requesting |  | none of the stored responses nominated in the conditional request |
| client, or act as if the server failed to respond. In the latter |  | is suitable. Instead, the cache can use the full response to |
| case, it MAY return a previously stored response (see Section 2.3.3). |  | satisfy the request and MAY replace the stored response(s). |
|  |  | o However, if a cache receives a 5xx response while attempting to |
|  |  | validate a response, it can either forward this response to the |
|  |  | requesting client, or act as if the server failed to respond. In |
|  |  | the latter case, it can return a previously stored response (see |
|  |  | Section 2.3.3). |
|  |  | 2.4.1. Freshening Responses |
|  |  | 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 |
|  |  | 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 |
|  |  | information provided in the 304 response. |
|  |  | o If the new response contains a strong validator, then that strong |
|  |  | validator identifies the selected representation. All of the |
|  |  | stored responses with the same strong validator are selected. If |
|  |  | none of the stored responses contain the same strong validator, |
|  |  | then this new response corresponds to a new selected |
|  |  | representation and MUST NOT update the existing stored responses. |
|  |  | o If the new response contains a weak validator and that validator |
|  |  | corresponds to one of the cache's stored responses, then the most |
|  |  | recent of those matching stored responses is selected. |
|  |  | 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 |
|  |  | validator, then that stored response is selected. |
|  |  | If a stored response is selected for update, the cache MUST: |
|  |  | o delete any Warning header fields in the stored response with warn- |
|  |  | code 1xx (see Section 3.6); |
|  |  | o retain any Warning header fields in the stored response with warn- |
|  |  | code 2xx; and, |
|  |  | o use other header fields provided in the 304 response to replace |
|  |  | all instances of the corresponding header fields in the stored |
|  |  | response. |
| 2.5. Request Methods that Invalidate |  | 2.5. Request Methods that Invalidate |
| Because unsafe request methods (Section 7.1.1 of [Part2]) such as |  | Because unsafe request methods (Section 6.1.1 of [Part2]) such as |
| PUT, POST or DELETE have the potential for changing state on the |  | PUT, POST or DELETE have the potential for changing state on the |
| origin server, intervening caches can use them to keep their contents |  | origin server, intervening caches can use them to keep their contents |
| up-to-date. |  | up-to-date. |
| A cache MUST invalidate the effective Request URI (Section 4.3 of |  | A cache MUST invalidate the effective Request URI (Section 4.3 of |
| [Part1]) as well as the URI(s) in the Location and Content-Location |  | [Part1]) as well as the URI(s) in the Location and Content-Location |
| header fields (if present) when a non-error response to a request |  | header fields (if present) when a non-error response to a request |
| with an unsafe method is received. |  | with an unsafe method is received. |
| However, a cache MUST NOT invalidate a URI from a Location or |  | However, a cache MUST NOT invalidate a URI from a Location or |
| Content-Location header field if the host part of that URI differs |  | Content-Location header field if the host part of that URI differs |
| from the host part in the effective request URI (Section 4.3 of |  | from the host part in the effective request URI (Section 4.3 of |
| [Part1]). This helps prevent denial of service attacks. |  | [Part1]). This helps prevent denial of service attacks. |
| A cache SHOULD invalidate the effective request URI (Section 4.3 of |  | A cache MUST invalidate the effective request URI (Section 4.3 of |
| [Part1]) when it receives a non-error response to a request with a |  | [Part1]) when it receives a non-error response to a request with a |
| method whose safety is unknown. |  | method whose safety is unknown. |
| Here, a "non-error response" is one with a 2xx or 3xx status code. |  | Here, a "non-error response" is one with a 2xx or 3xx status code. |
| "Invalidate" means that the cache will either remove all stored |  | "Invalidate" means that the cache will either remove all stored |
| responses related to the effective request URI, or will mark these as |  | responses related to the effective request URI, or will mark these as |
| "invalid" and in need of a mandatory validation before they can be |  | "invalid" and in need of a mandatory validation before they can be |
| returned in response to a subsequent request. |  | returned in response to a subsequent request. |
| Note that this does not guarantee that all appropriate responses are |  | Note that this does not guarantee that all appropriate responses are |
| skipping to change at page 18, line 44 |  | skipping to change at page 19, 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 2.2. |  | Section 2.2. |
| If no selected response is available, the cache MAY forward the |  | If no selected response is available, the cache can forward the |
| presented request to the origin server in a conditional request; see |  | presented request to the origin server in a conditional request; see |
| Section 2.4. |  | Section 2.4. |
| 2.8. Combining Partial Content |  | 2.8. 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 |
| skipping to change at page 19, line 23 |  | skipping to change at page 20, line 29 |
| o delete any Warning header fields in the stored response with warn- |  | o delete any Warning header fields in the stored response with warn- |
| code 1xx (see Section 3.6); |  | code 1xx (see Section 3.6); |
| o retain any Warning header fields in the stored response with warn- |  | o retain any Warning header fields in the stored response with warn- |
| code 2xx; and, |  | code 2xx; and, |
| o use other header fields provided in the 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. |
| 2.9. Freshening Responses |  |  |
| 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 |  |  |
| 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 |  |  |
| information provided in the 304 response. |  |  |
| o If the new response contains a strong validator, then that strong |  |  |
| validator identifies the selected representation. All of the |  |  |
| stored responses with the same strong validator are selected. If |  |  |
| none of the stored responses contain the same strong validator, |  |  |
| then this new response corresponds to a new selected |  |  |
| representation and MUST NOT update the existing stored responses. |  |  |
| o If the new response contains a weak validator and that validator |  |  |
| corresponds to one of the cache's stored responses, then the most |  |  |
| recent of those matching stored responses is selected. |  |  |
| 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 |  |  |
| validator, then that stored response is selected. |  |  |
| If a stored response is selected for update, the cache MUST: |  |  |
| o delete any Warning header fields in the stored response with warn- |  |  |
| code 1xx (see Section 3.6); |  |  |
| o retain any Warning header fields in the stored response with warn- |  |  |
| code 2xx; and, |  |  |
| o use other header fields provided in the 304 response to replace |  |  |
| all instances of the corresponding header fields in the stored |  |  |
| response. |  |  |
| 3. Header Field Definitions |  | 3. 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 |
| fields related to caching. |  | fields related to caching. |
| 3.1. Age |  | 3.1. Age |
| The "Age" header field conveys the sender's estimate of the amount of |  | The "Age" header field conveys the sender's estimate of the amount of |
| time since the response was generated or successfully validated at |  | time since the response was generated or successfully validated at |
| the origin server. Age values are calculated as specified in |  | the origin server. Age values are calculated as specified in |
| skipping to change at page 21, line 5 |  | skipping to change at page 21, line 25 |
| Note: HTTP/1.0 caches might not implement Cache-Control and might |  | Note: HTTP/1.0 caches might not implement Cache-Control and might |
| only implement Pragma: no-cache (see Section 3.4). |  | only implement Pragma: no-cache (see Section 3.4). |
| A proxy, whether or not it implements a cache, MUST pass cache |  | A proxy, whether or not it implements a cache, MUST pass cache |
| directives through in forwarded messages, regardless of their |  | directives through in forwarded messages, regardless of their |
| significance to that application, since the directives might be |  | significance to that application, since the directives might be |
| applicable to all recipients along the request/response chain. It is |  | applicable to all recipients along the request/response chain. It is |
| not possible to target a directive to a specific cache. |  | not possible to target a directive to a specific cache. |
|  |  | Cache directives are identified by a token, to be compared case- |
|  |  | insensitively, and have an optional argument. |
| Cache-Control = 1#cache-directive |  | Cache-Control = 1#cache-directive |
| cache-directive = cache-request-directive |  | cache-directive = cache-request-directive |
| / cache-response-directive |  | / cache-response-directive |
| cache-extension = token [ "=" ( token / quoted-string ) ] |  | cache-extension = token [ "=" ( token / quoted-string ) ] |
| 3.2.1. Request Cache-Control Directives |  | 3.2.1. Request Cache-Control Directives |
| cache-request-directive = |  | cache-request-directive = |
| skipping to change at page 24, line 48 |  | skipping to change at page 25, line 18 |
| become stale, a cache MUST NOT use the response to satisfy |  | become stale, a cache MUST NOT use the response to satisfy |
| subsequent requests without successful validation on the origin |  | subsequent requests without successful validation on the origin |
| server. |  | server. |
| The must-revalidate directive is necessary to support reliable |  | The must-revalidate directive is necessary to support reliable |
| operation for certain protocol features. In all circumstances a |  | operation for certain protocol features. In all circumstances a |
| cache MUST obey the must-revalidate directive; in particular, if a |  | cache MUST obey the must-revalidate directive; in particular, if a |
| cache cannot reach the origin server for any reason, it MUST |  | cache cannot reach the origin server for any reason, it MUST |
| generate a 504 (Gateway Timeout) response. |  | generate a 504 (Gateway Timeout) response. |
| A server SHOULD send the must-revalidate directive if and only if |  | The must-revalidate directive ought to be used by servers if and |
| failure to validate a request on the representation could result |  | only if failure to validate a request on the representation could |
| in incorrect operation, such as a silently unexecuted financial |  | result in incorrect operation, such as a silently unexecuted |
| transaction. |  | financial transaction. |
| proxy-revalidate |  | proxy-revalidate |
| The proxy-revalidate response directive has the same meaning as |  | The proxy-revalidate response directive has the same meaning as |
| the must-revalidate response directive, except that it does not |  | the must-revalidate response directive, except that it does not |
| apply to private caches. |  | apply to private caches. |
| max-age |  | max-age |
| The max-age response directive indicates that the response is to |  | The max-age response directive indicates that the response is to |
| skipping to change at page 26, line 52 |  | 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 2.3 for further discussion |  | response is considered stale. See Section 2.3 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 6.1 of [Part1]; a sender MUST use the rfc1123-date format. |  | in Section 8 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 27, line 26 |  | skipping to change at page 27, line 49 |
| Expires field. Likewise, the s-maxage directive overrides Expires |  | Expires field. Likewise, the s-maxage directive overrides Expires |
| in shared caches. |  | in shared caches. |
| 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 most caches will evict a response far sooner |  | for time values), and most caches will evict a response far sooner |
| than that. Therefore, senders ought not produce them. |  | than that. Therefore, senders ought not produce them. |
|  |  | 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). |
| 3.4. Pragma |  | 3.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 is also present and |  | HTTP/1.1). When the Cache-Control header 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 |
| implementation-specified directives for recipients. This |  | implementation-specified directives for recipients. This |
| specification deprecates such extensions to improve interoperability. |  | specification deprecates such extensions to improve interoperability. |
| Pragma = 1#pragma-directive |  | Pragma = 1#pragma-directive |
| pragma-directive = "no-cache" / extension-pragma |  | pragma-directive = "no-cache" / extension-pragma |
| extension-pragma = token [ "=" ( token / quoted-string ) ] |  | extension-pragma = token [ "=" ( token / quoted-string ) ] |
| When the Cache-Control header is not present in a request, the no- |  | When the Cache-Control header is not present in a request, the no- |
| cache request pragma-directive MUST have the same effect on caches as |  | cache request pragma-directive MUST have the same effect on caches as |
| if "Cache-Control: no-cache" were present (see Section 3.2.1). |  | if "Cache-Control: no-cache" were present (see Section 3.2.1). |
| When sending a no-cache request, a client SHOULD include both pragma |  | When sending a no-cache request, a client ought to include both the |
| and cache-control directives unless Cache-Control: no-cache is |  | pragma and cache-control directives, unless Cache-Control: no-cache |
| purposefully omitted to target other Cache-Control response |  | is purposefully omitted to target other Cache-Control response |
| directives at HTTP/1.1 caches. For example: |  | directives at HTTP/1.1 caches. For example: |
| GET / HTTP/1.1 |  | GET / HTTP/1.1 |
| Host: www.example.com |  | Host: www.example.com |
| Cache-Control: max-age=30 |  | Cache-Control: max-age=30 |
| 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. |
| skipping to change at page 29, line 45 |  | skipping to change at page 30, line 25 |
| warn-text = quoted-string |  | warn-text = quoted-string |
| warn-date = DQUOTE HTTP-date DQUOTE |  | warn-date = DQUOTE HTTP-date DQUOTE |
| Multiple warnings can be attached to a response (either by the origin |  | Multiple warnings can be attached to a response (either by the origin |
| server or by a cache), including multiple warnings with the same code |  | server or by a cache), including multiple warnings with the same code |
| number, only differing in warn-text. |  | number, only differing in warn-text. |
| When this occurs, the user agent SHOULD inform the user of as many of |  | When this occurs, the user agent SHOULD inform the user of as many of |
| them as possible, in the order that they appear in the response. |  | them as possible, in the order that they appear in the response. |
| Systems that generate multiple Warning header fields SHOULD order |  | Systems that generate multiple Warning header fields are encouraged |
| them with this user agent behavior in mind. New Warning header |  | to order them with this user agent behavior in mind. New Warning |
| fields SHOULD be added after any existing Warning headers fields. |  | header fields are added after any existing Warning headers fields. |
| Warnings are assigned three digit warn-codes. The first digit |  | Warnings are assigned three digit warn-codes. The first digit |
| indicates whether the Warning is required to be deleted from a stored |  | indicates whether the Warning is required to be deleted from a stored |
| 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. |
| skipping to change at page 30, line 45 |  | skipping to change at page 31, line 25 |
| stale. |  | stale. |
| 111 Revalidation failed |  | 111 Revalidation failed |
| A cache SHOULD include this when returning a stale response |  | A cache SHOULD include this when returning a stale response |
| because an attempt to validate the response failed, due to an |  | because an attempt to validate the response failed, due to an |
| inability to reach the server. |  | inability to reach the server. |
| 112 Disconnected operation |  | 112 Disconnected operation |
| A cache SHOULD b include this if it is intentionally disconnected |  | A cache SHOULD include this if it is intentionally disconnected |
| from the rest of the network for a period of time. |  | from the rest of the network for a period of time. |
| 113 Heuristic expiration |  | 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 |  | lifetime greater than 24 hours and the response's age is greater |
| than 24 hours. |  | than 24 hours. |
| 199 Miscellaneous warning |  | 199 Miscellaneous warning |
| skipping to change at page 33, line 7 |  | skipping to change at page 33, line 37 |
| 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. |
| 7. Acknowledgments |  | 7. Acknowledgments |
| See Section 12 of [Part1]. |  | See Section 11 of [Part1]. |
| 8. References |  | 8. References |
| 8.1. Normative References |  | 8.1. Normative References |
| [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, |  | and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, |
| and Message Parsing", draft-ietf-httpbis-p1-messaging-16 |  | and Message Parsing", draft-ietf-httpbis-p1-messaging-17 |
| (work in progress), August 2011. |  | (work in progress), October 2011. |
| [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| and J. Reschke, Ed., "HTTP/1.1, part 2: Message |  | and J. Reschke, Ed., "HTTP/1.1, part 2: Message |
| Semantics", draft-ietf-httpbis-p2-semantics-16 (work in |  | Semantics", draft-ietf-httpbis-p2-semantics-17 (work in |
| progress), August 2011. |  | progress), October 2011. |
| [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional |  | and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional |
| Requests", draft-ietf-httpbis-p4-conditional-16 (work in |  | Requests", draft-ietf-httpbis-p4-conditional-17 (work in |
| progress), August 2011. |  | progress), October 2011. |
| [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and |  | and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and |
| Partial Responses", draft-ietf-httpbis-p5-range-16 (work |  | Partial Responses", draft-ietf-httpbis-p5-range-17 (work |
| in progress), August 2011. |  | in progress), October 2011. |
| [Part7] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part7] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| and J. Reschke, Ed., "HTTP/1.1, part 7: Authentication", |  | and J. Reschke, Ed., "HTTP/1.1, part 7: Authentication", |
| draft-ietf-httpbis-p7-auth-16 (work in progress), |  | draft-ietf-httpbis-p7-auth-17 (work in progress), |
| August 2011. |  | October 2011. |
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |  | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |
| Requirement Levels", BCP 14, RFC 2119, March 1997. |  | Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax |  | [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax |
| Specifications: ABNF", STD 68, RFC 5234, January 2008. |  | Specifications: ABNF", STD 68, RFC 5234, January 2008. |
| 8.2. Informative References |  | 8.2. Informative References |
| [RFC1305] Mills, D., "Network Time Protocol (Version 3) |  | [RFC1305] Mills, D., "Network Time Protocol (Version 3) |
| skipping to change at page 34, line 48 |  | skipping to change at page 35, line 33 |
| Appendix B. Collected ABNF |  | Appendix B. Collected ABNF |
| Age = delta-seconds |  | Age = delta-seconds |
| Cache-Control = *( "," OWS ) cache-directive *( OWS "," [ OWS |  | Cache-Control = *( "," OWS ) cache-directive *( OWS "," [ OWS |
| cache-directive ] ) |  | cache-directive ] ) |
| Expires = HTTP-date |  | Expires = HTTP-date |
| HTTP-date = <HTTP-date, defined in [Part1], Section 6.1> |  | HTTP-date = <HTTP-date, defined in [Part2], Section 8> |
| OWS = <OWS, defined in [Part1], Section 1.2.2> |  | OWS = <OWS, defined in [Part1], Section 1.2.2> |
| Pragma = *( "," OWS ) pragma-directive *( OWS "," [ OWS |  | Pragma = *( "," OWS ) pragma-directive *( OWS "," [ OWS |
| pragma-directive ] ) |  | pragma-directive ] ) |
| Vary = "*" / ( *( "," OWS ) field-name *( OWS "," [ OWS field-name ] |  | Vary = "*" / ( *( "," OWS ) field-name *( OWS "," [ OWS field-name ] |
| ) ) |  | ) ) |
| Warning = *( "," OWS ) warning-value *( OWS "," [ OWS warning-value ] |  | Warning = *( "," OWS ) warning-value *( OWS "," [ OWS warning-value ] |
| ) |  | ) |
| cache-directive = cache-request-directive / cache-response-directive |  | cache-directive = cache-request-directive / cache-response-directive |
| skipping to change at page 35, line 34 |  | skipping to change at page 36, line 20 |
| ) / ( "s-maxage=" delta-seconds ) / cache-extension |  | ) / ( "s-maxage=" delta-seconds ) / cache-extension |
| delta-seconds = 1*DIGIT |  | delta-seconds = 1*DIGIT |
| extension-pragma = token [ "=" ( token / quoted-string ) ] |  | extension-pragma = token [ "=" ( token / quoted-string ) ] |
| field-name = <field-name, defined in [Part1], Section 3.2> |  | field-name = <field-name, defined in [Part1], Section 3.2> |
| port = <port, defined in [Part1], Section 2.7> |  | port = <port, defined in [Part1], Section 2.7> |
| pragma-directive = "no-cache" / extension-pragma |  | pragma-directive = "no-cache" / extension-pragma |
| pseudonym = <pseudonym, defined in [Part1], Section 9.9> |  | pseudonym = <pseudonym, defined in [Part1], Section 8.8> |
| quoted-string = <quoted-string, defined in [Part1], Section 3.2.3> |  | quoted-string = <quoted-string, defined in [Part1], Section 3.2.3> |
| token = <token, defined in [Part1], Section 3.2.3> |  | token = <token, defined in [Part1], Section 3.2.3> |
| 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 |
| skipping to change at page 41, line 25 |  | skipping to change at page 42, line 12 |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/292>: "Pragma" |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/292>: "Pragma" |
| C.17. Since draft-ietf-httpbis-p6-cache-15 |  | C.17. Since draft-ietf-httpbis-p6-cache-15 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/290>: "Motivate one- |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/290>: "Motivate one- |
| year limit for Expires" |  | year limit for Expires" |
|  |  | C.18. Since draft-ietf-httpbis-p6-cache-16 |
|  |  | Closed issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/186>: "Document |
|  |  | HTTP's error-handling philosophy" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/317>: "Cache-Control |
|  |  | directive case sensitivity" |
| Index |  | Index |
| A |  | A |
| age 6 |  | age 6 |
| Age header field 20 |  | Age header field 20 |
| C |  | C |
| cache 5 |  | cache 5 |
| Cache Directives |  | Cache Directives |
| max-age 21, 25 |  | max-age 22, 25 |
| max-stale 22 |  | max-stale 22 |
| min-fresh 22 |  | min-fresh 22 |
| must-revalidate 24 |  | must-revalidate 25 |
| no-cache 21, 23 |  | no-cache 21, 24 |
| no-store 21, 24 |  | no-store 22, 24 |
| no-transform 22, 25 |  | no-transform 23, 25 |
| only-if-cached 22 |  | only-if-cached 23 |
| private 23 |  | private 23 |
| proxy-revalidate 25 |  | proxy-revalidate 25 |
| public 23 |  | public 23 |
| s-maxage 25 |  | s-maxage 25 |
| cache entry 8 |  | cache entry 8 |
| cache key 8 |  | cache key 8 |
| Cache-Control header field 20 |  | Cache-Control header field 21 |
| cacheable 5 |  | cacheable 5 |
| E |  | E |
| Expires header field 26 |  | Expires header field 27 |
| explicit expiration time 6 |  | explicit expiration time 6 |
| F |  | F |
| first-hand 6 |  | first-hand 6 |
| fresh 6 |  | fresh 6 |
| freshness lifetime 6 |  | freshness lifetime 6 |
| G |  | G |
| Grammar |  | Grammar |
| Age 20 |  | Age 20 |
| Cache-Control 21 |  | Cache-Control 21 |
| cache-extension 21 |  | cache-extension 21 |
| cache-request-directive 21 |  | cache-request-directive 21 |
| cache-response-directive 23 |  | cache-response-directive 23 |
| delta-seconds 8 |  | delta-seconds 8 |
| Expires 27 |  | Expires 27 |
| extension-pragma 27 |  | extension-pragma 28 |
| Pragma 27 |  | Pragma 28 |
| pragma-directive 27 |  | pragma-directive 28 |
| Vary 28 |  | Vary 29 |
| warn-agent 29 |  | warn-agent 30 |
| warn-code 29 |  | warn-code 30 |
| warn-date 29 |  | warn-date 30 |
| warn-text 29 |  | warn-text 30 |
| Warning 29 |  | Warning 30 |
| warning-value 29 |  | warning-value 30 |
| H |  | H |
| Header Fields |  | Header Fields |
| Age 20 |  | Age 20 |
| Cache-Control 20 |  | Cache-Control 21 |
| Expires 26 |  | Expires 27 |
| Pragma 27 |  | Pragma 28 |
| Vary 28 |  | Vary 28 |
| Warning 29 |  | Warning 29 |
| heuristic expiration time 6 |  | heuristic expiration time 6 |
| M |  | M |
| max-age |  | max-age |
| Cache Directive 21, 25 |  | Cache Directive 22, 25 |
| max-stale |  | max-stale |
| Cache Directive 22 |  | Cache Directive 22 |
| min-fresh |  | min-fresh |
| Cache Directive 22 |  | Cache Directive 22 |
| must-revalidate |  | must-revalidate |
| Cache Directive 24 |  | Cache Directive 25 |
| N |  | N |
| no-cache |  | no-cache |
| Cache Directive 21, 23 |  |  |
| no-store |  |  |
| Cache Directive 21, 24 |  | Cache Directive 21, 24 |
|  |  | no-store |
|  |  | Cache Directive 22, 24 |
| no-transform |  | no-transform |
| Cache Directive 22, 25 |  | Cache Directive 23, 25 |
| O |  | O |
| only-if-cached |  | only-if-cached |
| Cache Directive 22 |  | Cache Directive 23 |
| P |  | P |
| Pragma header field 27 |  | Pragma header field 28 |
| private |  | private |
| Cache Directive 23 |  | Cache Directive 23 |
| private cache 5 |  | private cache 5 |
| proxy-revalidate |  | proxy-revalidate |
| Cache Directive 25 |  | Cache Directive 25 |
| public |  | public |
| Cache Directive 23 |  | Cache Directive 23 |
| S |  | S |
| s-maxage |  | s-maxage |
| skipping to change at page 45, line 26 |  | skipping to change at page 46, line 26 |
| World Wide Web Consortium |  | World Wide Web Consortium |
| W3C / ERCIM |  | W3C / ERCIM |
| 2004, rte des Lucioles |  | 2004, rte des Lucioles |
| Sophia-Antipolis, AM 06902 |  | Sophia-Antipolis, AM 06902 |
| France |  | France |
| EMail: ylafon@w3.org |  | EMail: ylafon@w3.org |
| URI: http://www.raubacapeu.net/people/yves/ |  | URI: http://www.raubacapeu.net/people/yves/ |
| Mark Nottingham (editor) |  | Mark Nottingham (editor) |
|  |  | Rackspace |
| 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 |
End of changes. 73 change blocks.
| 171 lines changed or deleted |  | 212 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/