| draft-ietf-httpbis-p6-cache-07.txt |  | draft-ietf-httpbis-p6-cache-08.txt |
--- | --- | --- | --- | ---
| HTTPbis Working Group R. Fielding, Ed. |  | HTTPbis Working Group R. Fielding, Ed. |
| Internet-Draft Day Software |  | Internet-Draft Day Software |
| Obsoletes: 2616 (if approved) J. Gettys |  | Obsoletes: 2616 (if approved) J. Gettys |
| Intended status: Standards Track One Laptop per Child |  | Intended status: Standards Track One Laptop per Child |
| Expires: January 14, 2010 J. Mogul |  | Expires: April 29, 2010 J. Mogul |
| HP |  | HP |
| H. Frystyk |  | H. Frystyk |
| Microsoft |  | Microsoft |
| L. Masinter |  | L. Masinter |
| Adobe Systems |  | Adobe Systems |
| 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. |
| J. Reschke, Ed. |  | J. Reschke, Ed. |
| greenbytes |  | greenbytes |
| July 13, 2009 |  | October 26, 2009 |
| HTTP/1.1, part 6: Caching |  | HTTP/1.1, part 6: Caching |
| draft-ietf-httpbis-p6-cache-07 |  | draft-ietf-httpbis-p6-cache-08 |
| Status of this Memo |  | Status of this Memo |
| This Internet-Draft is submitted to IETF in full conformance with the |  | This Internet-Draft is submitted to IETF in full conformance with the |
| provisions of BCP 78 and BCP 79. This document may contain material |  | provisions of BCP 78 and BCP 79. This document may contain material |
| from IETF Documents or IETF Contributions published or made publicly |  | from IETF Documents or IETF Contributions published or made publicly |
| available before November 10, 2008. The person(s) controlling the |  | available before November 10, 2008. The person(s) controlling the |
| copyright in some of this material may not have granted the IETF |  | copyright in some of this material may not have granted the IETF |
| Trust the right to allow modifications of such material outside the |  | Trust the right to allow modifications of such material outside the |
| IETF Standards Process. Without obtaining an adequate license from |  | IETF Standards Process. Without obtaining an adequate license from |
| skipping to change at page 2, line 13 |  | skipping to change at page 2, line 13 |
| 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." |
| The list of current Internet-Drafts can be accessed at |  | The list of current Internet-Drafts can be accessed at |
| http://www.ietf.org/ietf/1id-abstracts.txt. |  | http://www.ietf.org/ietf/1id-abstracts.txt. |
| The list of Internet-Draft Shadow Directories can be accessed at |  | The list of Internet-Draft Shadow Directories can be accessed at |
| http://www.ietf.org/shadow.html. |  | http://www.ietf.org/shadow.html. |
| This Internet-Draft will expire on January 14, 2010. |  | This Internet-Draft will expire on April 29, 2010. |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2009 IETF Trust and the persons identified as the |  | Copyright (c) 2009 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 in effect on the date of |  | Provisions Relating to IETF Documents in effect on the date of |
| publication of this document (http://trustee.ietf.org/license-info). |  | publication of this document (http://trustee.ietf.org/license-info). |
| Please review these documents carefully, as they describe your rights |  | Please review these documents carefully, as they describe your rights |
| skipping to change at page 2, line 44 |  | skipping to change at page 2, line 44 |
| or indicate cacheable response messages. |  | or indicate cacheable response messages. |
| Editorial Note (To be removed by RFC Editor) |  | Editorial Note (To be removed by RFC Editor) |
| 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). The current issues list is |  | group mailing list (ietf-http-wg@w3.org). The current issues list is |
| at <http://tools.ietf.org/wg/httpbis/trac/report/11> and related |  | at <http://tools.ietf.org/wg/httpbis/trac/report/11> 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.8. |  | The changes in this draft are summarized in Appendix C.9. |
| 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 . . . . . . . . . . . . . . . . . . . . . . . 6 |  | 1.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 |
| 1.4. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7 |  | 1.4. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7 |
| 1.4.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 7 |  | 1.4.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 7 |
| 1.4.2. ABNF Rules defined in other Parts of the |  | 1.4.2. ABNF Rules defined in other Parts of the |
| skipping to change at page 3, line 27 |  | skipping to change at page 3, line 27 |
| 2.1.1. Storing Partial and Incomplete Responses . . . . . . . 8 |  | 2.1.1. Storing Partial and Incomplete Responses . . . . . . . 8 |
| 2.2. Constructing Responses from Caches . . . . . . . . . . . . 8 |  | 2.2. Constructing Responses from Caches . . . . . . . . . . . . 8 |
| 2.3. Freshness Model . . . . . . . . . . . . . . . . . . . . . 9 |  | 2.3. Freshness Model . . . . . . . . . . . . . . . . . . . . . 9 |
| 2.3.1. Calculating Freshness Lifetime . . . . . . . . . . . . 10 |  | 2.3.1. Calculating Freshness Lifetime . . . . . . . . . . . . 10 |
| 2.3.2. Calculating Age . . . . . . . . . . . . . . . . . . . 11 |  | 2.3.2. Calculating Age . . . . . . . . . . . . . . . . . . . 11 |
| 2.3.3. Serving Stale Responses . . . . . . . . . . . . . . . 13 |  | 2.3.3. Serving Stale Responses . . . . . . . . . . . . . . . 13 |
| 2.4. Validation Model . . . . . . . . . . . . . . . . . . . . . 13 |  | 2.4. Validation Model . . . . . . . . . . . . . . . . . . . . . 13 |
| 2.5. Request Methods that Invalidate . . . . . . . . . . . . . 14 |  | 2.5. Request Methods that Invalidate . . . . . . . . . . . . . 14 |
| 2.6. Caching Negotiated Responses . . . . . . . . . . . . . . . 15 |  | 2.6. Caching Negotiated Responses . . . . . . . . . . . . . . . 15 |
| 2.7. Combining Responses . . . . . . . . . . . . . . . . . . . 16 |  | 2.7. Combining Responses . . . . . . . . . . . . . . . . . . . 16 |
| 3. Header Field Definitions . . . . . . . . . . . . . . . . . . . 17 |  | 3. Header Field Definitions . . . . . . . . . . . . . . . . . . . 16 |
| 3.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 |  | 3.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 |
| 3.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 17 |  | 3.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 17 |
| 3.2.1. Request Cache-Control Directives . . . . . . . . . . . 18 |  | 3.2.1. Request Cache-Control Directives . . . . . . . . . . . 18 |
| 3.2.2. Response Cache-Control Directives . . . . . . . . . . 20 |  | 3.2.2. Response Cache-Control Directives . . . . . . . . . . 20 |
| 3.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 22 |  | 3.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 22 |
| 3.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 23 |  | 3.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 23 |
| 3.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 23 |  | 3.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 24 |
| 3.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 |  | 3.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 |
| 3.6. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 25 |  | 3.6. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 25 |
| 4. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 28 |  | 4. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 28 |
| 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 |  | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 |
| 5.1. Message Header Registration . . . . . . . . . . . . . . . 28 |  | 5.1. Message Header Registration . . . . . . . . . . . . . . . 28 |
| 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 |  | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 |
| 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 |  | 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 |
| 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 |  | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 |
| 8.1. Normative References . . . . . . . . . . . . . . . . . . . 29 |  | 8.1. Normative References . . . . . . . . . . . . . . . . . . . 29 |
| 8.2. Informative References . . . . . . . . . . . . . . . . . . 30 |  | 8.2. Informative References . . . . . . . . . . . . . . . . . . 30 |
| Appendix A. Compatibility with Previous Versions . . . . . . . . 31 |  | Appendix A. Compatibility with Previous Versions . . . . . . . . 30 |
| A.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 31 |  | A.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 31 |
| A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 31 |  | A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 31 |
| Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 31 |  | Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 31 |
| Appendix C. Change Log (to be removed by RFC Editor before |  | Appendix C. Change Log (to be removed by RFC Editor before |
| publication) . . . . . . . . . . . . . . . . . . . . 33 |  | publication) . . . . . . . . . . . . . . . . . . . . 33 |
| C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 33 |  | C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 33 |
| C.2. Since draft-ietf-httpbis-p6-cache-00 . . . . . . . . . . . 33 |  | C.2. Since draft-ietf-httpbis-p6-cache-00 . . . . . . . . . . . 33 |
| C.3. Since draft-ietf-httpbis-p6-cache-01 . . . . . . . . . . . 34 |  | C.3. Since draft-ietf-httpbis-p6-cache-01 . . . . . . . . . . . 34 |
| C.4. Since draft-ietf-httpbis-p6-cache-02 . . . . . . . . . . . 34 |  | C.4. Since draft-ietf-httpbis-p6-cache-02 . . . . . . . . . . . 34 |
| C.5. Since draft-ietf-httpbis-p6-cache-03 . . . . . . . . . . . 34 |  | C.5. Since draft-ietf-httpbis-p6-cache-03 . . . . . . . . . . . 34 |
| C.6. Since draft-ietf-httpbis-p6-cache-04 . . . . . . . . . . . 35 |  | C.6. Since draft-ietf-httpbis-p6-cache-04 . . . . . . . . . . . 35 |
| C.7. Since draft-ietf-httpbis-p6-cache-05 . . . . . . . . . . . 35 |  | C.7. Since draft-ietf-httpbis-p6-cache-05 . . . . . . . . . . . 35 |
| C.8. Since draft-ietf-httpbis-p6-cache-06 . . . . . . . . . . . 35 |  | C.8. Since draft-ietf-httpbis-p6-cache-06 . . . . . . . . . . . 35 |
|  |  | C.9. Since draft-ietf-httpbis-p6-cache-07 . . . . . . . . . . . 36 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 |
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 |  | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 |
| 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. |
| skipping to change at page 7, line 38 |  | skipping to change at page 7, line 38 |
| The core rules below are defined in Section 1.2.2 of [Part1]: |  | The core rules below are defined in Section 1.2.2 of [Part1]: |
| quoted-string = <quoted-string, defined in [Part1], Section 1.2.2> |  | quoted-string = <quoted-string, defined in [Part1], Section 1.2.2> |
| token = <token, defined in [Part1], Section 1.2.2> |  | token = <token, defined in [Part1], Section 1.2.2> |
| OWS = <OWS, defined in [Part1], Section 1.2.2> |  | OWS = <OWS, defined in [Part1], Section 1.2.2> |
| 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 4.2> |  | field-name = <field-name, defined in [Part1], Section 3.2> |
| HTTP-date = <HTTP-date, defined in [Part1], Section 3.2> |  | HTTP-date = <HTTP-date, defined in [Part1], Section 6.1> |
| port = <port, defined in [Part1], Section 2.1> |  | port = <port, defined in [Part1], Section 2.6> |
| pseudonym = <pseudonym, defined in [Part1], Section 8.9> |  | pseudonym = <pseudonym, defined in [Part1], Section 9.9> |
| uri-host = <uri-host, defined in [Part1], Section 2.1> |  | uri-host = <uri-host, defined in [Part1], Section 2.6> |
| 2. Cache Operation |  | 2. Cache Operation |
| 2.1. Response Cacheability |  | 2.1. Response Cacheability |
| A cache MUST NOT store a response to any request, unless: |  | A cache MUST NOT store a response to any request, unless: |
| o The request method is defined as being cacheable, and |  | o The request method is defined as being cacheable, and |
| o the "no-store" cache directive (see Section 3.2) does not appear |  | o the "no-store" cache directive (see Section 3.2) does not appear |
| skipping to change at page 8, line 47 |  | skipping to change at page 8, line 47 |
| MUST NOT store incomplete or partial responses. |  | MUST NOT store incomplete or partial responses. |
| 2.2. Constructing Responses from Caches |  | 2.2. Constructing Responses from Caches |
| For a presented request, a cache MUST NOT return a stored response, |  | For a presented request, a cache MUST NOT return a stored response, |
| unless: |  | unless: |
| o The presented Request-URI and that of the stored response match |  | o The presented Request-URI and that of the stored response match |
| ([[TODO-Request-URI: Need to find a new term for this, as Part 1 |  | ([[TODO-Request-URI: Need to find a new term for this, as Part 1 |
| doesn't define Request-URI anymore; the new term request-target |  | doesn't define Request-URI anymore; the new term request-target |
| does not work for this.]]), and |  | does not work for this. (see |
|  |  | <http://tools.ietf.org/wg/httpbis/trac/ticket/196>)]]), and |
| o the request method associated with the stored response allows it |  | o the request method associated with the stored response allows it |
| to be used for the presented request, and |  | to be used for the presented request, and |
| o selecting request-headers nominated by the stored response (if |  | o selecting request-headers nominated by the stored response (if |
| any) match those presented (see Section 2.6), and |  | any) match those presented (see Section 2.6), and |
| o the presented request and stored response are free from directives |  | o the presented request and stored response are free from directives |
| that would prevent its use (see Section 3.2 and Section 3.4), and |  | that would prevent its use (see Section 3.2 and Section 3.4), and |
| o the stored response is either: |  | o the stored response is either: |
| skipping to change at page 11, line 51 |  | skipping to change at page 11, line 51 |
| generated or validated by the origin server. In essence, the Age |  | generated or validated by the origin server. In essence, the Age |
| value is the sum of the time that the response has been resident in |  | value is the sum of the time that the response has been resident in |
| each of the caches along the path from the origin server, plus the |  | each of the caches along the path from the origin server, plus the |
| amount of time it has been in transit along network paths. |  | amount of time it has been in transit along network paths. |
| The term "age_value" denotes the value of the Age header, in a form |  | The term "age_value" denotes the value of the Age header, in a form |
| appropriate for arithmetic operations. |  | appropriate for arithmetic operations. |
| HTTP/1.1 requires origin servers to send a Date header, if possible, |  | HTTP/1.1 requires origin servers to send a Date header, if possible, |
| with every response, giving the time at which the response was |  | with every response, giving the time at which the response was |
| generated (see Section 8.3 of [Part1]). The term "date_value" |  | generated (see Section 9.3 of [Part1]). The term "date_value" |
| denotes the value of the Date header, in a form appropriate for |  | denotes the value of the Date header, in a form appropriate for |
| arithmetic operations. |  | arithmetic operations. |
| 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." Hosts that use HTTP, but especially |  | performing the calculation." Hosts that use HTTP, but especially |
| hosts running origin servers and caches, SHOULD use NTP [RFC1305] or |  | hosts running origin servers and caches, SHOULD use NTP [RFC1305] or |
| some similar protocol to synchronize their clocks to a globally |  | some similar protocol to synchronize their clocks to a globally |
| accurate time standard. |  | accurate time standard. |
| A response's age can be calculated in two entirely independent ways: |  | A response's age can be calculated in two entirely independent ways: |
| skipping to change at page 14, line 34 |  | skipping to change at page 14, line 34 |
| of the stored responses nominated in the conditional request is |  | of the stored responses nominated in the conditional request is |
| suitable. Instead, the full response is used both to satisfy the |  | suitable. Instead, the full response is used both to satisfy the |
| request and replace the stored response. [[anchor5: Should there be a |  | request and replace the stored response. [[anchor5: Should there be a |
| requirement here?]] |  | requirement here?]] |
| If a cache receives a 5xx response while attempting to validate a |  | If a cache receives a 5xx response while attempting to validate a |
| response, it MAY either forward this response to the requesting |  | response, it MAY either forward this response to the requesting |
| client, or act as if the server failed to respond. In the latter |  | client, or act as if the server failed to respond. In the latter |
| case, it MAY return a previously stored response (see Section 2.3.3). |  | case, it MAY return a previously stored response (see Section 2.3.3). |
| If a cache receives a successful response whose Content-Location |  |  |
| field matches that of an existing stored response for the same |  |  |
| Request-URI, whose entity-tag differs from that of the existing |  |  |
| stored response, and whose Date is more recent than that of the |  |  |
| existing response, the existing response SHOULD NOT be returned in |  |  |
| response to future requests and SHOULD be deleted from the cache. |  |  |
| [[anchor6: DISCUSS: Not sure if this is necessary.]] |  |  |
| 2.5. Request Methods that Invalidate |  | 2.5. Request Methods that Invalidate |
| Because unsafe methods (Section 7.1.1 of [Part2]) have the potential |  | Because unsafe methods (Section 7.1.1 of [Part2]) have the potential |
| for changing state on the origin server, intervening caches can use |  | for changing state on the origin server, intervening caches can use |
| them to keep their contents up-to-date. |  | them to keep their contents up-to-date. |
| The following HTTP methods MUST cause a cache to invalidate the |  | The following HTTP methods MUST cause a cache to invalidate the |
| Request-URI as well as the URI(s) in the Location and Content- |  | Request-URI as well as the URI(s) in the Location and Content- |
| Location headers (if present): |  | Location headers (if present): |
| skipping to change at page 15, line 16 |  | skipping to change at page 15, line 7 |
| o DELETE |  | o DELETE |
| o POST |  | o POST |
| An invalidation based on a URI from a Location or Content-Location |  | An invalidation based on a URI from a Location or Content-Location |
| header MUST NOT be performed if the host part of that URI differs |  | header MUST NOT be performed if the host part of that URI differs |
| from the host part in the Request-URI. This helps prevent denial of |  | from the host part in the Request-URI. This helps prevent denial of |
| service attacks. |  | service attacks. |
| [[anchor7: TODO: "host part" needs to be specified better.]] |  | [[anchor6: TODO: "host part" needs to be specified better.]] |
| A cache that passes through requests for methods it does not |  | A cache that passes through requests for methods it does not |
| understand SHOULD invalidate the Request-URI. |  | understand SHOULD invalidate the Request-URI. |
| Here, "invalidate" means that the cache will either remove all stored |  | Here, "invalidate" means that the cache will either remove all stored |
| responses related to the Request-URI, or will mark these as "invalid" |  | responses related to the Request-URI, or will mark these as "invalid" |
| and in need of a mandatory validation before they can be returned in |  | and in need of a mandatory validation before they can be returned in |
| response to a subsequent request. |  | response to a subsequent request. |
| Note that this does not guarantee that all appropriate responses are |  | Note that this does not guarantee that all appropriate responses are |
| invalidated. For example, the request that caused the change at the |  | invalidated. For example, the request that caused the change at the |
| origin server might not have gone through the cache where a response |  | origin server might not have gone through the cache where a response |
| is stored. |  | is stored. |
| [[anchor8: TODO: specify that only successful (2xx, 3xx?) responses |  | [[anchor7: TODO: specify that only successful (2xx, 3xx?) responses |
| invalidate.]] |  | invalidate.]] |
| 2.6. Caching Negotiated Responses |  | 2.6. Caching Negotiated Responses |
| When a cache receives a request that can be satisfied by a stored |  | When a cache receives a request that can be satisfied by a stored |
| response that has a Vary header field (Section 3.5), it MUST NOT use |  | response that has a Vary header field (Section 3.5), it MUST NOT use |
| that response unless all of the selecting request-headers nominated |  | that response unless all of the selecting request-headers nominated |
| by the Vary header match in both the original request (i.e., that |  | by the Vary header match in both the original request (i.e., that |
| associated with the stored response), and the presented request. |  | associated with the stored response), and the presented request. |
| The selecting request-headers from two requests are defined to match |  | The selecting request-headers from two requests are defined to match |
| if and only if the selecting request-headers in the first request can |  | if and only if the selecting request-headers in the first request can |
| be transformed to the selecting request-headers in the second request |  | be transformed to the selecting request-headers in the second request |
| by adding or removing linear white space [[anchor9: [ref]]] at places |  | by adding or removing linear white space [[anchor8: [ref]]] at places |
| where this is allowed by the corresponding ABNF, and/or combining |  | where this is allowed by the corresponding ABNF, and/or combining |
| multiple message-header fields with the same field name following the |  | multiple message-header fields with the same field name following the |
| rules about message headers in Section 4.2 of [Part1]. |  | rules about header fields in Section 3.2 of [Part1]. |
| If a header field is absent from a request, it can only match another |  | If a header field is absent from a request, it can only match another |
| request if it is also absent there. |  | request if it is also absent there. |
| A Vary header field-value of "*" always fails to match, and |  | A Vary header field-value of "*" always fails to match, and |
| 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 request-headers is known |  | The stored response with matching selecting request-headers is known |
| as the selected response. |  | as the selected response. |
| skipping to change at page 16, line 25 |  | skipping to change at page 16, line 16 |
| 2.7. Combining Responses |  | 2.7. Combining Responses |
| When a cache receives a 304 (Not Modified) response or a 206 (Partial |  | When a cache receives a 304 (Not Modified) response or a 206 (Partial |
| Content) response (in this section, the "new" response"), it needs to |  | Content) response (in this section, the "new" response"), it needs to |
| created an updated response by combining the stored response with the |  | created an updated response by combining the stored response with the |
| new one, so that the updated response can be used to satisfy the |  | new one, so that the updated response can be used to satisfy the |
| request. |  | request. |
| If the new response contains an ETag, it identifies the stored |  | If the new response contains an ETag, it identifies the stored |
| response to use. [[anchor10: may need language about Content-Location |  | response to use. [[anchor9: may need language about Content-Location |
| here]][[anchor11: cover case where INM with multiple etags was sent]] |  | here]][[anchor10: cover case where INM with multiple etags was sent]] |
| If the status code is 206 (partial content), both the stored and new |  | If the status code is 206 (partial content), both the stored and new |
| responses MUST have ETags, and those ETags MUST match using the |  | responses MUST have validators, and those validators MUST match using |
| strong comparison function (see Section 4 of [Part4]). Otherwise, |  | the strong comparison function (see Section 4 of [Part4]). |
| the responses MUST NOT be combined. |  | Otherwise, the responses MUST NOT be combined. |
| The stored response headers are used as those of the updated |  | The stored response headers are used as those of the updated |
| response, except that |  | response, except that |
| o any stored Warning headers with warn-code 1xx (see Section 3.6) |  | o any stored Warning headers with warn-code 1xx (see Section 3.6) |
| MUST be deleted from the stored response and the updated response. |  | MUST be deleted from the stored response and the updated response. |
| o any stored Warning headers with warn-code 2xx MUST be retained in |  | o any stored Warning headers with warn-code 2xx MUST be retained in |
| the stored response and the updated response. |  | the stored response and the updated response. |
| o any headers provided in the new response MUST replace the |  | o any headers provided in the new response MUST replace the |
| corresponding headers from the stored response. |  | corresponding headers from the stored response. |
| If a header field-name in the new response matches more than one |  | If a header field-name in the new response matches more than one |
| header in the stored response, all such stored headers MUST be |  | header in the stored response, all such stored headers MUST be |
| replaced. |  | replaced. |
| The updated response can [[[[anchor12: requirement?]]]] be used to |  | The updated response can [[[[anchor11: requirement?]]]] be used to |
| replace the stored response in cache. In the case of a 206 response, |  | replace the stored response in cache. In the case of a 206 response, |
| the combined entity-body MAY be stored. |  | the combined entity-body MAY be stored. |
| [[anchor13: ISSUE: discuss how to handle HEAD updates]] |  | [[anchor12: ISSUE: discuss how to handle HEAD updates]] |
| 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. |
| For entity-header fields, both sender and recipient refer to either |  | For entity-header fields, both sender and recipient refer to either |
| the client or the server, depending on who sends and who receives the |  | the client or the server, depending on who sends and who receives the |
| entity. |  | entity. |
| 3.1. Age |  | 3.1. Age |
| The response-header field "Age" conveys the sender's estimate of the |  | The "Age" response-header field conveys the sender's estimate of the |
| amount of time since the response (or its validation) was generated |  | amount of time since the response was generated or successfully |
| at the origin server. Age values are calculated as specified in |  | validated at the origin server. Age values are calculated as |
| Section 2.3.2. |  | specified in Section 2.3.2. |
| Age = "Age" ":" OWS Age-v |  | Age = "Age" ":" OWS Age-v |
| Age-v = delta-seconds |  | Age-v = delta-seconds |
| Age field-values are non-negative integers, representing time in |  | Age field-values are non-negative integers, representing time in |
| seconds. |  | seconds. |
| delta-seconds = 1*DIGIT |  | delta-seconds = 1*DIGIT |
| If a cache receives a value larger than the largest positive integer |  | If a cache receives a value larger than the largest positive integer |
| it can represent, or if any of its age calculations overflows, it |  | it can represent, or if any of its age calculations overflows, it |
| MUST transmit an Age header with a field-value of 2147483648 (2^31). |  | MUST transmit an Age header with a field-value of 2147483648 (2^31). |
| Caches SHOULD use an arithmetic type of at least 31 bits of range. |  | Caches SHOULD use an arithmetic type of at least 31 bits of range. |
| The presence of an Age header field in a response implies that a |  | The presence of an Age header field in a response implies that a |
| response is not first-hand. However, the converse is not true, since |  | response is not first-hand. However, the converse is not true, since |
| HTTP/1.0 caches may not implement the Age header field. |  | HTTP/1.0 caches may not implement the Age header field. |
| 3.2. Cache-Control |  | 3.2. Cache-Control |
| The general-header field "Cache-Control" is used to specify |  | The "Cache-Control" general-header field is used to specify |
| directives that MUST be obeyed by all caches along the request/ |  | directives that MUST be obeyed by all caches along the request/ |
| response chain. The directives specify behavior intended to prevent |  | response chain. Such cache directives are unidirectional in that the |
| caches from adversely interfering with the request or response. |  | presence of a directive in a request does not imply that the same |
| Cache directives are unidirectional in that the presence of a |  | directive is to be given in the response. |
| directive in a request does not imply that the same directive is to |  |  |
| be given in the response. |  |  |
| Note that HTTP/1.0 caches might not implement Cache-Control and |  | Note that HTTP/1.0 caches might not implement Cache-Control and |
| might only implement Pragma: no-cache (see Section 3.4). |  | might only implement Pragma: no-cache (see Section 3.4). |
| Cache directives MUST be passed through by a proxy or gateway |  | Cache directives MUST be passed through by a proxy or gateway |
| application, regardless of their significance to that application, |  | application, regardless of their significance to that application, |
| since the directives might be applicable to all recipients along the |  | since the directives might be applicable to all recipients along the |
| request/response chain. It is not possible to target a directive to |  | request/response chain. It is not possible to target a directive to |
| a specific cache. |  | a specific cache. |
| skipping to change at page 19, line 21 |  | skipping to change at page 19, line 13 |
| client is not willing to accept a stale response. |  | client is not willing to accept a stale response. |
| max-stale |  | max-stale |
| The max-stale request directive indicates that the client is |  | The max-stale request directive indicates that the client is |
| willing to accept a response that has exceeded its expiration |  | willing to accept a response that has exceeded its expiration |
| time. If max-stale is assigned a value, then the client is |  | time. If max-stale is assigned a value, then the client is |
| willing to accept a response that has exceeded its expiration time |  | willing to accept a response that has exceeded its expiration time |
| by no more than the specified number of seconds. If no value is |  | by no more than the specified number of seconds. If no value is |
| assigned to max-stale, then the client is willing to accept a |  | assigned to max-stale, then the client is willing to accept a |
| stale response of any age. [[anchor14: of any staleness? --mnot]] |  | stale response of any age. [[anchor13: of any staleness? --mnot]] |
| min-fresh |  | min-fresh |
| The min-fresh request directive indicates that the client is |  | The min-fresh request directive indicates that the client is |
| willing to accept a response whose freshness lifetime is no less |  | willing to accept a response whose freshness lifetime is no less |
| than its current age plus the specified time in seconds. That is, |  | than its current age plus the specified time in seconds. That is, |
| the client wants a response that will still be fresh for at least |  | the client wants a response that will still be fresh for at least |
| the specified number of seconds. |  | the specified number of seconds. |
| no-transform |  | no-transform |
| skipping to change at page 20, line 40 |  | skipping to change at page 20, line 40 |
| cache. A private (non-shared) cache MAY store the response. |  | cache. A private (non-shared) cache MAY store the response. |
| If the private response directive specifies one or more field- |  | If the private response directive specifies one or more field- |
| names, this requirement is limited to the field-values associated |  | names, this requirement is limited to the field-values associated |
| with the listed response headers. That is, the specified field- |  | with the listed response headers. That is, the specified field- |
| names(s) MUST NOT be stored by a shared cache, whereas the |  | names(s) MUST NOT be stored by a shared cache, whereas the |
| remainder of the response message MAY be. |  | remainder of the response message MAY be. |
| Note: This usage of the word private only controls where the |  | Note: This usage of the word private only controls where the |
| response may be stored, and cannot ensure the privacy of the |  | response may be stored, and cannot ensure the privacy of the |
| message content. |  | message content. Also, private response directives with field- |
|  |  | names are often handled by implementations as if an unqualified |
|  |  | private directive was recieved; i.e., the special handling for the |
|  |  | qualified form is not widely implemented. |
| no-cache |  | no-cache |
| The no-cache response directive indicates that the response MUST |  | The no-cache response directive indicates that the response MUST |
| NOT be used to satisfy a subsequent request without successful |  | NOT be used to satisfy a subsequent request without successful |
| validation on the origin server. This allows an origin server to |  | validation on the origin server. This allows an origin server to |
| prevent caching even by caches that have been configured to return |  | prevent caching even by caches that have been configured to return |
| stale responses. |  | stale responses. |
| If the no-cache response directive specifies one or more field- |  | If the no-cache response directive specifies one or more field- |
| names, this requirement is limited to the field-values associated |  | names, this requirement is limited to the field-values associated |
| with the listed response headers. That is, the specified field- |  | with the listed response headers. That is, the specified field- |
| name(s) MUST NOT be sent in the response to a subsequent request |  | name(s) MUST NOT be sent in the response to a subsequent request |
| without successful validation on the origin server. This allows |  | without successful validation on the origin server. This allows |
| an origin server to prevent the re-use of certain header fields in |  | an origin server to prevent the re-use of certain header fields in |
| a response, while still allowing caching of the rest of the |  | a response, while still allowing caching of the rest of the |
| response. |  | response. |
| Note: Most HTTP/1.0 caches will not recognize or obey this |  | Note: Most HTTP/1.0 caches will not recognize or obey this |
| directive. |  | directive. Also, no-cache response directives with field-names |
|  |  | are often handled by implementations as if an unqualified no-cache |
|  |  | directive was recieved; i.e., the special handling for the |
|  |  | qualified form is not widely implemented. |
| no-store |  | no-store |
| The no-store response directive indicates that a cache MUST NOT |  | The no-store response directive indicates that a cache MUST NOT |
| store any part of either the immediate request or response. This |  | store any part of either the immediate request or response. This |
| directive applies to both non-shared and shared caches. "MUST NOT |  | directive applies to both non-shared and shared caches. "MUST NOT |
| store" in this context means that the cache MUST NOT intentionally |  | store" in this context means that the cache MUST NOT intentionally |
| store the information in non-volatile storage, and MUST make a |  | store the information in non-volatile storage, and MUST make a |
| best-effort attempt to remove the information from volatile |  | best-effort attempt to remove the information from volatile |
| storage as promptly as possible after forwarding it. |  | storage as promptly as possible after forwarding it. |
| skipping to change at page 23, line 17 |  | skipping to change at page 23, line 24 |
| behavior. |  | behavior. |
| Unrecognized cache directives MUST be ignored; it is assumed that any |  | Unrecognized cache directives MUST be ignored; it is assumed that any |
| cache directive likely to be unrecognized by an HTTP/1.1 cache will |  | cache directive likely to be unrecognized by an HTTP/1.1 cache will |
| be combined with standard directives (or the response's default |  | be combined with standard directives (or the response's default |
| cacheability) such that the cache behavior will remain minimally |  | cacheability) such that the cache behavior will remain minimally |
| correct even if the cache does not understand the extension(s). |  | correct even if the cache does not understand the extension(s). |
| 3.3. Expires |  | 3.3. Expires |
| The entity-header field "Expires" gives the date/time after which the |  | The "Expires" entity-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 3.2 of [Part1]; it MUST be sent in rfc1123-date format. |  | in Section 6.1 of [Part1]; it MUST be sent in rfc1123-date format. |
| Expires = "Expires" ":" OWS Expires-v |  | Expires = "Expires" ":" OWS Expires-v |
| Expires-v = HTTP-date |  | Expires-v = HTTP-date |
| For example |  | For example |
| Expires: Thu, 01 Dec 1994 16:00:00 GMT |  | Expires: Thu, 01 Dec 1994 16:00:00 GMT |
| Note: if a response includes a Cache-Control field with the max- |  | Note: if a response includes a Cache-Control field with the max- |
| age directive (see Section 3.2.2), that directive overrides the |  | age directive (see Section 3.2.2), that directive overrides the |
| skipping to change at page 23, line 49 |  | skipping to change at page 24, line 8 |
| HTTP/1.1 servers SHOULD NOT send Expires dates more than one year in |  | HTTP/1.1 servers SHOULD NOT send Expires dates more than one year in |
| the future. |  | the future. |
| HTTP/1.1 clients and caches MUST treat other invalid date formats, |  | HTTP/1.1 clients and caches MUST treat other invalid date formats, |
| especially including the value "0", as in the past (i.e., "already |  | especially including the value "0", as in the past (i.e., "already |
| expired"). |  | expired"). |
| 3.4. Pragma |  | 3.4. Pragma |
| The general-header field "Pragma" is used to include implementation- |  | The "Pragma" general-header field is used to include implementation- |
| specific directives that might apply to any recipient along the |  | specific directives that might apply to any recipient along the |
| request/response chain. All pragma directives specify optional |  | request/response chain. All pragma directives specify optional |
| behavior from the viewpoint of the protocol; however, some systems |  | behavior from the viewpoint of the protocol; however, some systems |
| MAY require that behavior be consistent with the directives. |  | MAY require that behavior be consistent with the directives. |
| Pragma = "Pragma" ":" OWS Pragma-v |  | Pragma = "Pragma" ":" OWS Pragma-v |
| Pragma-v = 1#pragma-directive |  | Pragma-v = 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 ) ] |
| skipping to change at page 24, line 31 |  | skipping to change at page 24, line 38 |
| Note: because the meaning of "Pragma: no-cache" as a response- |  | Note: because the meaning of "Pragma: no-cache" as a response- |
| header field is not actually specified, it does not provide a |  | header field is not actually specified, it does not provide a |
| reliable replacement for "Cache-Control: no-cache" in a response. |  | reliable replacement for "Cache-Control: no-cache" in a response. |
| This mechanism is deprecated; no new Pragma directives will be |  | This mechanism is deprecated; no new Pragma directives will be |
| defined in HTTP. |  | defined in HTTP. |
| 3.5. Vary |  | 3.5. Vary |
| The "Vary" response-header field's value indicates the set of |  | The "Vary" response-header field conveys the set of request-header |
| request-header fields that determines, while the response is fresh, |  | fields that were used to select the representation. |
| whether a cache is permitted to use the response to reply to a |  |  |
| subsequent request without validation; see Section 2.6. |  | Caches use this information, in part, to determine whether a stored |
|  |  | response can be used to satisdy a given request; see Section 2.6. |
|  |  | determines, while the response is fresh, whether a cache is permitted |
|  |  | to use the response to reply to a subsequent request without |
|  |  | validation; see Section 2.6. |
| In uncacheable or stale responses, the Vary field value advises the |  | In uncacheable or stale responses, the Vary field value advises the |
| user agent about the criteria that were used to select the |  | user agent about the criteria that were used to select the |
| representation. |  | representation. |
| Vary = "Vary" ":" OWS Vary-v |  | Vary = "Vary" ":" OWS Vary-v |
| Vary-v = "*" / 1#field-name |  | Vary-v = "*" / 1#field-name |
| The set of header fields named by the Vary field value is known as |  | The set of header fields named by the Vary field value is known as |
| the selecting request-headers. |  | the selecting request-headers. |
| skipping to change at page 25, line 21 |  | skipping to change at page 25, line 32 |
| therefore, a cache cannot determine whether this response is |  | therefore, a cache cannot determine whether this response is |
| appropriate. The "*" value MUST NOT be generated by a proxy server; |  | appropriate. The "*" value MUST NOT be generated by a proxy server; |
| it may only be generated by an origin server. |  | it may only be generated by an origin server. |
| The field-names given are not limited to the set of standard request- |  | The field-names given are not limited to the set of standard request- |
| header fields defined by this specification. Field names are case- |  | header fields defined by this specification. Field names are case- |
| insensitive. |  | insensitive. |
| 3.6. Warning |  | 3.6. Warning |
| The general-header field "Warning" is used to carry additional |  | The "Warning" general-header field is used to carry additional |
| information about the status or transformation of a message that |  | information about the status or transformation of a message that |
| might not be reflected in the message. This information is typically |  | might not be reflected in the message. This information is typically |
| used to warn about possible incorrectness introduced by caching |  | used to warn about possible incorrectness introduced by caching |
| operations or transformations applied to the entity body of the |  | operations or transformations applied to the entity body of the |
| message. |  | 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, |
| distinguish these responses from true failures. |  | distinguish these responses from true failures. |
| skipping to change at page 25, line 51 |  | skipping to change at page 26, line 20 |
| warn-code = 3DIGIT |  | warn-code = 3DIGIT |
| warn-agent = ( uri-host [ ":" port ] ) / pseudonym |  | warn-agent = ( uri-host [ ":" port ] ) / pseudonym |
| ; the name or pseudonym of the server adding |  | ; the name or pseudonym of the server adding |
| ; the Warning header, for use in debugging |  | ; the Warning header, for use in debugging |
| 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. For example, a server might provide the same warning with |  | number, only differing in warn-text. |
| texts in both English and Basque. |  |  |
| 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. If |  | them as possible, in the order that they appear in the response. |
| it is not possible to inform the user of all of the warnings, the |  |  |
| user agent SHOULD follow these heuristics: |  |  |
| o Warnings that appear early in the response take priority over |  |  |
| those appearing later in the response. |  |  |
| o Warnings in the user's preferred character set take priority over |  |  |
| warnings in other character sets but with identical warn-codes and |  |  |
| warn-agents. |  |  |
| Systems that generate multiple Warning headers SHOULD order them with |  | Systems that generate multiple Warning headers SHOULD order them with |
| this user agent behavior in mind. New Warning headers SHOULD be |  | this user agent behavior in mind. New Warning headers SHOULD be |
| added after any existing Warning headers. |  | added after any existing Warning headers. |
| 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 that describe the freshness or validation status of |  | o 1xx Warnings describe the freshness or validation status of the |
| the response, and so MUST be deleted by caches after validation. |  | response, and so MUST be deleted by caches after validation. They |
| They MUST NOT be generated by a cache except when validating a |  | can only be generated by a cache when validating a cached entry, |
| cached entry, and MUST NOT be generated by clients. |  | and MUST NOT be generated in any other situation. |
| o 2xx Warnings that describe some aspect of the entity body or |  | o 2xx Warnings describe some aspect of the entity body or entity |
| entity headers that is not rectified by a validation (for example, |  | headers that is not rectified by a validation (for example, a |
| a lossy compression of the entity bodies) and MUST NOT be deleted |  | lossy compression of the entity bodies) and MUST NOT be deleted by |
| by caches after validation, unless a full response is returned, in |  | caches after validation, unless a full response is returned, in |
| which case they MUST be. |  | which case they MUST be. |
| The warn-text SHOULD be in a natural language and character set that |  |  |
| is most likely to be intelligible to the human user receiving the |  |  |
| response. This decision can be based on any available knowledge, |  |  |
| such as the location of the cache or user, the Accept-Language field |  |  |
| in a request, the Content-Language field in a response, etc. The |  |  |
| default language is English and the default character set is ISO- |  |  |
| 8859-1 ([ISO-8859-1]). |  |  |
| If a character set other than ISO-8859-1 is used, it MUST be encoded |  |  |
| in the warn-text using the method described in [RFC2047]. |  |  |
| If an implementation sends a message with one or more Warning headers |  | If an implementation sends a message with one or more Warning headers |
| to a receiver whose version is HTTP/1.0 or lower, then the sender |  | to a receiver whose version is HTTP/1.0 or lower, then the sender |
| MUST include in each warning-value a warn-date that matches the Date |  | MUST include in each warning-value a warn-date that matches the Date |
| header in the message. |  | header in the message. |
| If an implementation receives a message with a warning-value that |  | If an implementation receives a message with a warning-value that |
| includes a warn-date, and that warn-date is different from the Date |  | includes a warn-date, and that warn-date is different from the Date |
| value in the response, then that warning-value MUST be deleted from |  | value in the response, then that warning-value MUST be deleted from |
| the message before storing, forwarding, or using it. (preventing the |  | the message before storing, forwarding, or using it. (preventing the |
| consequences of naive caching of Warning header fields.) If all of |  | consequences of naive caching of Warning header fields.) If all of |
| skipping to change at page 29, line 39 |  | skipping to change at page 29, line 39 |
| 7. Acknowledgments |  | 7. Acknowledgments |
| Much of the content and presentation of the caching design is due to |  | Much of the content and presentation of the caching design is due to |
| suggestions and comments from individuals including: Shel Kaphan, |  | suggestions and comments from individuals including: Shel Kaphan, |
| Paul Leach, Koen Holtman, David Morris, and Larry Masinter. |  | Paul Leach, Koen Holtman, David Morris, and Larry Masinter. |
| 8. References |  | 8. References |
| 8.1. Normative References |  | 8.1. Normative References |
| [ISO-8859-1] |  |  |
| International Organization for Standardization, |  |  |
| "Information technology -- 8-bit single-byte coded graphic |  |  |
| character sets -- Part 1: Latin alphabet No. 1", ISO/ |  |  |
| IEC 8859-1:1998, 1998. |  |  |
| [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-07 |  | and Message Parsing", draft-ietf-httpbis-p1-messaging-08 |
| (work in progress), July 2009. |  | (work in progress), October 2009. |
| [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-07 (work in |  | Semantics", draft-ietf-httpbis-p2-semantics-08 (work in |
| progress), July 2009. |  | progress), October 2009. |
| [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part3] 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 3: Message Payload |  | and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload |
| and Content Negotiation", draft-ietf-httpbis-p3-payload-07 |  | and Content Negotiation", draft-ietf-httpbis-p3-payload-08 |
| (work in progress), July 2009. |  | (work in progress), October 2009. |
| [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-07 (work in |  | Requests", draft-ietf-httpbis-p4-conditional-08 (work in |
| progress), July 2009. |  | progress), October 2009. |
| [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-07 (work |  | Partial Responses", draft-ietf-httpbis-p5-range-08 (work |
| in progress), July 2009. |  | in progress), October 2009. |
| [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-07 (work in progress), |  | draft-ietf-httpbis-p7-auth-08 (work in progress), |
| July 2009. |  | October 2009. |
| [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) |  |  |
| Part Three: Message Header Extensions for Non-ASCII Text", |  |  |
| RFC 2047, November 1996. |  |  |
| [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 31, line 20 |  | skipping to change at page 31, line 14 |
| A.1. Changes from RFC 2068 |  | A.1. Changes from RFC 2068 |
| A case was missed in the Cache-Control model of HTTP/1.1; s-maxage |  | A case was missed in the Cache-Control model of HTTP/1.1; s-maxage |
| was introduced to add this missing case. (Sections 2.1, 3.2). |  | was introduced to add this missing case. (Sections 2.1, 3.2). |
| Transfer-coding and message lengths all interact in ways that |  | Transfer-coding and message lengths all interact in ways that |
| required fixing exactly when chunked encoding is used (to allow for |  | required fixing exactly when chunked encoding is used (to allow for |
| transfer encoding that may not be self delimiting); it was important |  | transfer encoding that may not be self delimiting); it was important |
| to straighten out exactly how message lengths are computed. (see also |  | to straighten out exactly how message lengths are computed. (see also |
| [Part1], [Part3] and [Part5]) [[anchor17: This used to refer to the |  | [Part1], [Part3] and [Part5]) [[anchor16: This used to refer to the |
| text about non-modifiable headers, and will have to be updated later |  | text about non-modifiable headers, and will have to be updated later |
| on. --jre]] |  | on. --jre]] |
| Proxies should be able to add Content-Length when appropriate. |  | Proxies should be able to add Content-Length when appropriate. |
| [[anchor18: This used to refer to the text about non-modifiable |  | [[anchor17: This used to refer to the text about non-modifiable |
| headers, and will have to be updated later on. --jre]] |  | headers, and will have to be updated later on. --jre]] |
| Range request responses would become very verbose if all meta-data |  | Range request responses would become very verbose if all meta-data |
| were always returned; by allowing the server to only send needed |  | were always returned; by allowing the server to only send needed |
| headers in a 206 response, this problem can be avoided. |  | headers in a 206 response, this problem can be avoided. |
| (Section 2.7) |  | (Section 2.7) |
| The Cache-Control: max-age directive was not properly defined for |  | The Cache-Control: max-age directive was not properly defined for |
| responses. (Section 3.2.2) |  | responses. (Section 3.2.2) |
| Warnings could be cached incorrectly, or not updated appropriately. |  | Warnings could be cached incorrectly, or not updated appropriately. |
| (Section 2.3, 2.7, 3.2, and 3.6) Warning also needed to be a general |  | (Section 2.3, 2.7, 3.2, and 3.6) Warning also needed to be a general |
| header, as PUT or other methods may have need for it in requests. |  | header, as PUT or other methods may have need for it in requests. |
| A.2. Changes from RFC 2616 |  | A.2. Changes from RFC 2616 |
|  |  | Remove requirement to consider Content-Location in successful |
|  |  | responses in order to determine the appropriate response to use. |
|  |  | (Section 2.4) |
| Clarify denial of service attack avoidance requirement. |  | Clarify denial of service attack avoidance requirement. |
| (Section 2.5) |  | (Section 2.5) |
|  |  | Do not mention RFC 2047 encoding and multiple languages in Warning |
|  |  | headers anymore, as these aspects never were implemented. |
|  |  | (Section 3.6) |
| Appendix B. Collected ABNF |  | Appendix B. Collected ABNF |
| Age = "Age:" OWS Age-v |  | Age = "Age:" OWS Age-v |
| Age-v = delta-seconds |  | Age-v = delta-seconds |
| Cache-Control = "Cache-Control:" OWS Cache-Control-v |  | Cache-Control = "Cache-Control:" OWS Cache-Control-v |
| Cache-Control-v = *( "," OWS ) cache-directive *( OWS "," [ OWS |  | Cache-Control-v = *( "," OWS ) cache-directive *( OWS "," [ OWS |
| cache-directive ] ) |  | cache-directive ] ) |
| Expires = "Expires:" OWS Expires-v |  | Expires = "Expires:" OWS Expires-v |
| Expires-v = HTTP-date |  | Expires-v = HTTP-date |
| HTTP-date = <HTTP-date, defined in [Part1], Section 3.2> |  | HTTP-date = <HTTP-date, defined in [Part1], Section 6.1> |
| OWS = <OWS, defined in [Part1], Section 1.2.2> |  | OWS = <OWS, defined in [Part1], Section 1.2.2> |
| Pragma = "Pragma:" OWS Pragma-v |  | Pragma = "Pragma:" OWS Pragma-v |
| Pragma-v = *( "," OWS ) pragma-directive *( OWS "," [ OWS |  | Pragma-v = *( "," OWS ) pragma-directive *( OWS "," [ OWS |
| pragma-directive ] ) |  | pragma-directive ] ) |
| Vary = "Vary:" OWS Vary-v |  | Vary = "Vary:" OWS Vary-v |
| Vary-v = "*" / ( *( "," OWS ) field-name *( OWS "," [ OWS field-name |  | Vary-v = "*" / ( *( "," OWS ) field-name *( OWS "," [ OWS field-name |
| ] ) ) |  | ] ) ) |
| skipping to change at page 32, line 43 |  | skipping to change at page 32, line 44 |
| OWS ) field-name *( OWS "," [ OWS field-name ] ) DQUOTE ] ) / ( |  | OWS ) field-name *( OWS "," [ OWS field-name ] ) DQUOTE ] ) / ( |
| "no-cache" [ "=" DQUOTE *( "," OWS ) field-name *( OWS "," [ OWS |  | "no-cache" [ "=" DQUOTE *( "," OWS ) field-name *( OWS "," [ OWS |
| field-name ] ) DQUOTE ] ) / "no-store" / "no-transform" / |  | field-name ] ) DQUOTE ] ) / "no-store" / "no-transform" / |
| "must-revalidate" / "proxy-revalidate" / ( "max-age=" delta-seconds |  | "must-revalidate" / "proxy-revalidate" / ( "max-age=" delta-seconds |
| ) / ( "s-maxage=" delta-seconds ) / cache-extension |  | ) / ( "s-maxage=" delta-seconds ) / cache-extension |
| delta-seconds = 1*DIGIT |  | delta-seconds = 1*DIGIT |
| extension-pragma = token [ "=" ( token / quoted-string ) ] |  | extension-pragma = token [ "=" ( token / quoted-string ) ] |
| field-name = <field-name, defined in [Part1], Section 4.2> |  | field-name = <field-name, defined in [Part1], Section 3.2> |
| port = <port, defined in [Part1], Section 2.1> |  | port = <port, defined in [Part1], Section 2.6> |
| pragma-directive = "no-cache" / extension-pragma |  | pragma-directive = "no-cache" / extension-pragma |
| pseudonym = <pseudonym, defined in [Part1], Section 8.9> |  | pseudonym = <pseudonym, defined in [Part1], Section 9.9> |
| quoted-string = <quoted-string, defined in [Part1], Section 1.2.2> |  | quoted-string = <quoted-string, defined in [Part1], Section 1.2.2> |
| token = <token, defined in [Part1], Section 1.2.2> |  | token = <token, defined in [Part1], Section 1.2.2> |
| uri-host = <uri-host, defined in [Part1], Section 2.1> |  |  |
|  |  | uri-host = <uri-host, defined in [Part1], Section 2.6> |
| 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 |
| ] |  | ] |
| ABNF diagnostics: |  | ABNF diagnostics: |
| skipping to change at page 36, line 5 |  | skipping to change at page 36, line 5 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/161>: "base for |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/161>: "base for |
| numeric protocol elements" |  | numeric protocol elements" |
| Affected issues: |  | Affected issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/37>: Vary and non- |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/37>: Vary and non- |
| existant headers |  | existant headers |
|  |  | C.9. Since draft-ietf-httpbis-p6-cache-07 |
|  |  | Closed issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/54>: "Definition of |
|  |  | 1xx Warn-Codes" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/167>: "Content- |
|  |  | Location on 304 responses" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/169>: "private and |
|  |  | no-cache CC directives with headers" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/187>: "RFC2047 and |
|  |  | warn-text" |
| Index |  | Index |
| A |  | A |
| age 6 |  | age 6 |
| Age header 17 |  | Age header 17 |
| C |  | C |
| cache 5 |  | cache 5 |
| Cache Directives |  | Cache Directives |
| max-age 19, 21 |  | max-age 18, 22 |
| max-stale 19 |  | max-stale 19 |
| min-fresh 19 |  | min-fresh 19 |
| must-revalidate 21 |  | must-revalidate 21 |
| no-cache 18, 20 |  | no-cache 18, 20 |
| no-store 18, 21 |  | no-store 18, 21 |
| no-transform 19, 22 |  | no-transform 19, 22 |
| only-if-cached 19 |  | only-if-cached 19 |
| private 20 |  | private 20 |
| proxy-revalidate 21 |  | proxy-revalidate 21 |
| public 20 |  | public 20 |
| skipping to change at page 37, line 7 |  | skipping to change at page 37, line 24 |
| cache-response-directive 20 |  | cache-response-directive 20 |
| delta-seconds 17 |  | delta-seconds 17 |
| Expires 23 |  | Expires 23 |
| Expires-v 23 |  | Expires-v 23 |
| extension-pragma 24 |  | extension-pragma 24 |
| Pragma 24 |  | Pragma 24 |
| pragma-directive 24 |  | pragma-directive 24 |
| Pragma-v 24 |  | Pragma-v 24 |
| Vary 24 |  | Vary 24 |
| Vary-v 24 |  | Vary-v 24 |
| warn-agent 25 |  | warn-agent 26 |
| warn-code 25 |  | warn-code 26 |
| warn-date 25 |  | warn-date 26 |
| warn-text 25 |  | warn-text 26 |
| Warning 25 |  | Warning 26 |
| Warning-v 25 |  | Warning-v 26 |
| warning-value 25 |  | warning-value 26 |
| H |  | H |
| Headers |  | Headers |
| Age 17 |  | Age 17 |
| Cache-Control 17 |  | Cache-Control 17 |
| Expires 23 |  | Expires 23 |
| Pragma 23 |  | Pragma 24 |
| Vary 24 |  | Vary 24 |
| Warning 25 |  | Warning 25 |
| heuristic expiration time 5 |  | heuristic expiration time 5 |
| M |  | M |
| max-age |  | max-age |
| Cache Directive 19, 21 |  | Cache Directive 18, 22 |
| max-stale |  | max-stale |
| Cache Directive 19 |  | Cache Directive 19 |
| min-fresh |  | min-fresh |
| Cache Directive 19 |  | Cache Directive 19 |
| must-revalidate |  | must-revalidate |
| Cache Directive 21 |  | Cache Directive 21 |
| N |  | N |
| no-cache |  | no-cache |
| Cache Directive 18, 20 |  | Cache Directive 18, 20 |
| no-store |  | no-store |
| Cache Directive 18, 21 |  | Cache Directive 18, 21 |
| no-transform |  | no-transform |
| Cache Directive 19, 22 |  | Cache Directive 19, 22 |
| O |  | O |
| only-if-cached |  | only-if-cached |
| skipping to change at page 37, line 48 |  | skipping to change at page 38, line 17 |
| no-store |  | no-store |
| Cache Directive 18, 21 |  | Cache Directive 18, 21 |
| no-transform |  | no-transform |
| Cache Directive 19, 22 |  | Cache Directive 19, 22 |
| O |  | O |
| only-if-cached |  | only-if-cached |
| Cache Directive 19 |  | Cache Directive 19 |
| P |  | P |
| Pragma header 23 |  | Pragma header 24 |
| private |  | private |
| Cache Directive 20 |  | Cache Directive 20 |
| proxy-revalidate |  | proxy-revalidate |
| Cache Directive 21 |  | Cache Directive 21 |
| public |  | public |
| Cache Directive 20 |  | Cache Directive 20 |
| S |  | S |
| s-maxage |  | s-maxage |
| Cache Directive 22 |  | Cache Directive 22 |
End of changes. 62 change blocks.
| 129 lines changed or deleted |  | 122 lines changed or added |
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/