| draft-ietf-httpbis-p6-cache-09.txt |  | draft-ietf-httpbis-p6-cache-10.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 Alcatel-Lucent |
| Expires: September 9, 2010 J. Mogul |  | Expires: January 13, 2011 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 |
| March 8, 2010 |  | July 12, 2010 |
| HTTP/1.1, part 6: Caching |  | HTTP/1.1, part 6: Caching |
| draft-ietf-httpbis-p6-cache-09 |  | draft-ietf-httpbis-p6-cache-10 |
| Abstract |  | Abstract |
| The Hypertext Transfer Protocol (HTTP) is an application-level |  | The Hypertext Transfer Protocol (HTTP) is an application-level |
| protocol for distributed, collaborative, hypermedia information |  | protocol for distributed, collaborative, hypermedia information |
| systems. This document is Part 6 of the seven-part specification |  | systems. This document is Part 6 of the seven-part specification |
| that defines the protocol referred to as "HTTP/1.1" and, taken |  | that defines the protocol referred to as "HTTP/1.1" and, taken |
| together, obsoletes RFC 2616. Part 6 defines requirements on HTTP |  | together, obsoletes RFC 2616. Part 6 defines requirements on HTTP |
| caches and the associated header fields that control cache behavior |  | caches and the associated header fields that control cache behavior |
| 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/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.10. |  | The changes in this draft are summarized in Appendix C.11. |
| 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 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), its areas, and its working groups. Note that |  | Task Force (IETF). Note that other groups may also distribute |
| other groups may also distribute working documents as Internet- |  | working documents as Internet-Drafts. The list of current Internet- |
| Drafts. |  | 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." |
| The list of current Internet-Drafts can be accessed at |  | This Internet-Draft will expire on January 13, 2011. |
| http://www.ietf.org/ietf/1id-abstracts.txt. |  |  |
| The list of Internet-Draft Shadow Directories can be accessed at |  |  |
| http://www.ietf.org/shadow.html. |  |  |
| This Internet-Draft will expire on September 9, 2010. |  |  |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2010 IETF Trust and the persons identified as the |  | Copyright (c) 2010 IETF Trust and the persons identified as the |
| document authors. All rights reserved. |  | document authors. All rights reserved. |
| This document is subject to BCP 78 and the IETF Trust's Legal |  | This document is subject to BCP 78 and the IETF Trust's Legal |
| Provisions Relating to IETF Documents |  | Provisions Relating to IETF Documents |
| (http://trustee.ietf.org/license-info) in effect on the date of |  | (http://trustee.ietf.org/license-info) in effect on the date of |
| publication of this document. Please review these documents |  | publication of this document. Please review these documents |
| carefully, as they describe your rights and restrictions with respect |  | carefully, as they describe your rights and restrictions with respect |
| to this document. Code Components extracted from this document must |  | to this document. Code Components extracted from this document must |
| include Simplified BSD License text as described in Section 4.e of |  | include Simplified BSD License text as described in Section 4.e of |
| the Trust Legal Provisions and are provided without warranty as |  | the Trust Legal Provisions and are provided without warranty as |
| described in the BSD License. |  | described in the Simplified BSD License. |
| This document may contain material from IETF Documents or IETF |  | This document may contain material from IETF Documents or IETF |
| Contributions published or made publicly available before November |  | Contributions published or made publicly available before November |
| 10, 2008. The person(s) controlling the copyright in some of this |  | 10, 2008. The person(s) controlling the copyright in some of this |
| material may not have granted the IETF Trust the right to allow |  | material may not have granted the IETF Trust the right to allow |
| modifications of such material outside the IETF Standards Process. |  | modifications of such material outside the IETF Standards Process. |
| Without obtaining an adequate license from the person(s) controlling |  | Without obtaining an adequate license from the person(s) controlling |
| the copyright in such materials, this document may not be modified |  | the copyright in such materials, this document may not be modified |
| 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 |
| skipping to change at page 3, line 25 |  | skipping to change at page 3, line 18 |
| 2. Cache Operation . . . . . . . . . . . . . . . . . . . . . . . 7 |  | 2. Cache Operation . . . . . . . . . . . . . . . . . . . . . . . 7 |
| 2.1. Response Cacheability . . . . . . . . . . . . . . . . . . 7 |  | 2.1. Response Cacheability . . . . . . . . . . . . . . . . . . 7 |
| 2.1.1. Storing Partial and Incomplete Responses . . . . . . . 8 |  | 2.1.1. Storing Partial and Incomplete Responses . . . . . . . 8 |
| 2.2. Constructing Responses from Caches . . . . . . . . . . . . 9 |  | 2.2. Constructing Responses from Caches . . . . . . . . . . . . 9 |
| 2.3. Freshness Model . . . . . . . . . . . . . . . . . . . . . 10 |  | 2.3. Freshness Model . . . . . . . . . . . . . . . . . . . . . 10 |
| 2.3.1. Calculating Freshness Lifetime . . . . . . . . . . . . 11 |  | 2.3.1. Calculating Freshness Lifetime . . . . . . . . . . . . 11 |
| 2.3.2. Calculating Age . . . . . . . . . . . . . . . . . . . 12 |  | 2.3.2. Calculating Age . . . . . . . . . . . . . . . . . . . 12 |
| 2.3.3. Serving Stale Responses . . . . . . . . . . . . . . . 13 |  | 2.3.3. Serving Stale Responses . . . . . . . . . . . . . . . 13 |
| 2.4. Validation Model . . . . . . . . . . . . . . . . . . . . . 14 |  | 2.4. Validation Model . . . . . . . . . . . . . . . . . . . . . 14 |
| 2.5. Request Methods that Invalidate . . . . . . . . . . . . . 14 |  | 2.5. Request Methods that Invalidate . . . . . . . . . . . . . 14 |
| 2.6. Caching Negotiated Responses . . . . . . . . . . . . . . . 15 |  | 2.6. Shared Caching of Authenticated Responses . . . . . . . . 15 |
| 2.7. Combining Responses . . . . . . . . . . . . . . . . . . . 16 |  | 2.7. Caching Negotiated Responses . . . . . . . . . . . . . . . 16 |
|  |  | 2.8. Combining Responses . . . . . . . . . . . . . . . . . . . 16 |
| 3. Header Field Definitions . . . . . . . . . . . . . . . . . . . 17 |  | 3. Header Field Definitions . . . . . . . . . . . . . . . . . . . 17 |
| 3.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 |  | 3.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 |
| 3.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 18 |  | 3.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 18 |
| 3.2.1. Request Cache-Control Directives . . . . . . . . . . . 18 |  | 3.2.1. Request Cache-Control Directives . . . . . . . . . . . 19 |
| 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 . . . . . . . . . . . . . . . 23 |
| 3.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 23 |  | 3.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 24 |
| 3.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 24 |  | 3.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 25 |
| 3.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 |  | 3.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 |
| 3.6. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 25 |  | 3.6. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 26 |
| 4. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 28 |  | 4. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 29 |
| 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 |  | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 |
| 5.1. Message Header Registration . . . . . . . . . . . . . . . 28 |  | 5.1. Cache Directive Registry . . . . . . . . . . . . . . . . . 29 |
| 6. Security Considerations . . . . . . . . . . . . . . . . . . . 28 |  | 5.2. Message Header Registration . . . . . . . . . . . . . . . 30 |
| 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 |  | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 30 |
| 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 |  | 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 |
| 8.1. Normative References . . . . . . . . . . . . . . . . . . . 29 |  | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 |
| 8.2. Informative References . . . . . . . . . . . . . . . . . . 30 |  | 8.1. Normative References . . . . . . . . . . . . . . . . . . . 30 |
| Appendix A. Compatibility with Previous Versions . . . . . . . . 30 |  | 8.2. Informative References . . . . . . . . . . . . . . . . . . 31 |
| A.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 30 |  | Appendix A. Compatibility with Previous Versions . . . . . . . . 32 |
| A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 30 |  | A.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 32 |
| Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 31 |  | A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 32 |
|  |  | Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 32 |
| Appendix C. Change Log (to be removed by RFC Editor before |  | Appendix C. Change Log (to be removed by RFC Editor before |
| publication) . . . . . . . . . . . . . . . . . . . . 32 |  | publication) . . . . . . . . . . . . . . . . . . . . 34 |
| C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 32 |  | C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 34 |
| C.2. Since draft-ietf-httpbis-p6-cache-00 . . . . . . . . . . . 32 |  | C.2. Since draft-ietf-httpbis-p6-cache-00 . . . . . . . . . . . 34 |
| C.3. Since draft-ietf-httpbis-p6-cache-01 . . . . . . . . . . . 33 |  | C.3. Since draft-ietf-httpbis-p6-cache-01 . . . . . . . . . . . 35 |
| C.4. Since draft-ietf-httpbis-p6-cache-02 . . . . . . . . . . . 33 |  | C.4. Since draft-ietf-httpbis-p6-cache-02 . . . . . . . . . . . 35 |
| C.5. Since draft-ietf-httpbis-p6-cache-03 . . . . . . . . . . . 34 |  | C.5. Since draft-ietf-httpbis-p6-cache-03 . . . . . . . . . . . 35 |
| C.6. Since draft-ietf-httpbis-p6-cache-04 . . . . . . . . . . . 34 |  | C.6. Since draft-ietf-httpbis-p6-cache-04 . . . . . . . . . . . 35 |
| C.7. Since draft-ietf-httpbis-p6-cache-05 . . . . . . . . . . . 34 |  | C.7. Since draft-ietf-httpbis-p6-cache-05 . . . . . . . . . . . 36 |
| C.8. Since draft-ietf-httpbis-p6-cache-06 . . . . . . . . . . . 35 |  | C.8. Since draft-ietf-httpbis-p6-cache-06 . . . . . . . . . . . 36 |
| C.9. Since draft-ietf-httpbis-p6-cache-07 . . . . . . . . . . . 35 |  | C.9. Since draft-ietf-httpbis-p6-cache-07 . . . . . . . . . . . 36 |
| C.10. Since draft-ietf-httpbis-p6-cache-08 . . . . . . . . . . . 35 |  | C.10. Since draft-ietf-httpbis-p6-cache-08 . . . . . . . . . . . 37 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 |  | C.11. Since draft-ietf-httpbis-p6-cache-09 . . . . . . . . . . . 37 |
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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. |
| 1.1. Purpose |  | 1.1. Purpose |
| skipping to change at page 7, line 4 |  | skipping to change at page 7, line 4 |
| A cache that is accessible to more than one user. A non-shared |  | A cache that is accessible to more than one user. A non-shared |
| cache is dedicated to a single user. |  | cache is dedicated to a single user. |
| 1.3. Requirements |  | 1.3. Requirements |
| 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 |  | An implementation is not compliant if it fails to satisfy one or more |
| of the MUST or REQUIRED level requirements for the protocols it |  | of the "MUST" or "REQUIRED" level requirements for the protocols it |
| implements. An implementation that satisfies all the MUST or |  | implements. An implementation that satisfies all the "MUST" or |
| REQUIRED level and all the SHOULD level requirements for its |  | "REQUIRED" level and all the "SHOULD" level requirements for its |
| protocols is said to be "unconditionally compliant"; one that |  | protocols is said to be "unconditionally compliant"; one that |
| satisfies all the MUST level requirements but not all the SHOULD |  | satisfies all the "MUST" level requirements but not all the "SHOULD" |
| level requirements for its protocols is said to be "conditionally |  | level requirements for its protocols is said to be "conditionally |
| compliant." |  | compliant". |
| 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 |
| skipping to change at page 8, line 17 |  | skipping to change at page 8, line 14 |
| o the response status code is understood by the cache, and |  | o the response status code is understood by the cache, and |
| o the "no-store" cache directive (see Section 3.2) does not appear |  | o the "no-store" cache directive (see Section 3.2) does not appear |
| in request or response headers, and |  | in request or response headers, and |
| o the "private" cache response directive (see Section 3.2.2 does not |  | o the "private" cache response directive (see Section 3.2.2 does not |
| appear in the response, if the cache is shared, and |  | appear in the response, if the cache is shared, and |
| o the "Authorization" header (see Section 3.1 of [Part7]) does not |  | o the "Authorization" header (see Section 3.1 of [Part7]) does not |
| appear in the request, if the cache is shared (unless the "public" |  | appear in the request, if the cache is shared, unless the response |
| directive is present; see Section 3.2), and |  | explicitly allows it (see Section 2.6), and |
| o the response either: |  | o the response either: |
| * contains an Expires header (see Section 3.3), or |  | * contains an Expires header (see Section 3.3), or |
| * contains a max-age response cache directive (see |  | * contains a max-age response cache directive (see |
| Section 3.2.2), or |  | Section 3.2.2), or |
| * contains a s-maxage response cache directive and the cache is |  | * contains a s-maxage response cache directive and the cache is |
| shared, or |  | shared, or |
| skipping to change at page 9, line 18 |  | skipping to change at page 9, line 14 |
| status code. |  | status code. |
| A cache that does not support the Range and Content-Range headers |  | A cache that does not support the Range and Content-Range headers |
| 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 Effective Request URI (Section 4.3 of [Part1]) and |
| ([[TODO-Request-URI: Need to find a new term for this, as Part 1 |  | that of the stored response match, and |
| doesn't define Request-URI anymore; the new term request-target |  |  |
| 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.7), 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: |
| * fresh (see Section 2.3), or |  | * fresh (see Section 2.3), or |
| * allowed to be served stale (see Section 2.3.3), or |  | * allowed to be served stale (see Section 2.3.3), or |
| skipping to change at page 10, line 14 |  | skipping to change at page 10, line 8 |
| having received a corresponding response. |  | 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. |
| Caches MUST use the most recent response (as determined by the Date |  | Caches MUST use the most recent response (as determined by the Date |
| header) when more than one suitable response is stored. They can |  | header) when more than one suitable response is stored. They can |
| also forward a request with "Cache-Control: max-age=0" or "Cache- |  | 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. |
| [[TODO-header-properties: end-to-end and hop-by-hop headers, non- |  |  |
| modifiable headers removed; re-spec in p1]] |  |  |
| 2.3. Freshness Model |  | 2.3. Freshness Model |
| When a response is "fresh" in the cache, it can be used to satisfy |  | When a response is "fresh" in the cache, it can be used to satisfy |
| subsequent requests without contacting the origin server, thereby |  | subsequent requests without contacting the origin server, thereby |
| improving efficiency. |  | improving efficiency. |
| The primary mechanism for determining freshness is for an origin |  | The primary mechanism for determining freshness is for an origin |
| server to provide an explicit expiration time in the future, using |  | server to provide an explicit expiration time in the future, using |
| either the Expires header (Section 3.3) or the max-age response cache |  | either the Expires header (Section 3.3) or the max-age response cache |
| directive (Section 3.2.2). Generally, origin servers will assign |  | directive (Section 3.2.2). Generally, origin servers will assign |
| skipping to change at page 11, line 32 |  | skipping to change at page 11, line 22 |
| o If the cache is shared and the s-maxage response cache directive |  | o If the cache is shared and the s-maxage response cache directive |
| (Section 3.2.2) is present, use its value, or |  | (Section 3.2.2) is present, use its value, or |
| o If the max-age response cache directive (Section 3.2.2) is |  | o If the max-age response cache directive (Section 3.2.2) is |
| present, use its value, or |  | present, use its value, or |
| o If the Expires response header (Section 3.3) is present, use its |  | o If the Expires response header (Section 3.3) is present, use its |
| value minus the value of the Date response header, or |  | value minus the value of the Date response header, or |
| o Otherwise, no explicit expiration time is present in the response, |  | o Otherwise, no explicit expiration time is present in the response. |
| but a heuristic may be used; see Section 2.3.1.1. |  | A heuristic freshness lifetime might be applicable; see |
|  |  | 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 of 200, 203, 206, 300, 301 or 410, a heuristic |  | has a status code of 200, 203, 206, 300, 301 or 410, a heuristic |
| expiration time can be calculated. Heuristics MUST NOT be used for |  | expiration time can be calculated. Heuristics MUST NOT be used for |
| other response status codes. |  | other response status codes. |
| skipping to change at page 12, line 6 |  | skipping to change at page 11, line 46 |
| When a heuristic is used to calculate freshness lifetime, the cache |  | When a heuristic is used to calculate freshness lifetime, the cache |
| SHOULD attach a Warning header with a 113 warn-code to the response |  | SHOULD attach a Warning header with a 113 warn-code to the response |
| if its current_age is more than 24 hours and such a warning is not |  | if its current_age is more than 24 hours and such a warning is not |
| already present. |  | already present. |
| Also, if the response has a Last-Modified header (Section 6.6 of |  | Also, if the response has a Last-Modified header (Section 6.6 of |
| [Part4]), the heuristic expiration value SHOULD be no more than some |  | [Part4]), the heuristic expiration value SHOULD be no more than some |
| fraction of the interval since that time. A typical setting of this |  | fraction of the interval since that time. A typical setting of this |
| fraction might be 10%. |  | fraction might be 10%. |
| [[REVIEW-query-string-heuristics: took away HTTP/1.0 query string |  | Note: RFC 2616 ([RFC2616], Section 13.9) required that caches do |
| heuristic uncacheability.]] |  | not calculate heuristic freshness for URLs with query components |
|  |  | (i.e., those containing '?'). In practice, this has not been |
|  |  | widely implemented. Therefore, servers are encouraged to send |
|  |  | explicit directives (e.g., Cache-Control: no-cache) if they wish |
|  |  | to preclude caching. |
| 2.3.2. Calculating Age |  | 2.3.2. Calculating Age |
| HTTP/1.1 uses the Age response-header to convey the estimated age of |  | HTTP/1.1 uses the Age response-header to convey the estimated age of |
| the response message when obtained from a cache. The Age field value |  | the response message when obtained from a cache. The Age field value |
| is the cache's estimate of the amount of time since the response was |  | is the cache's estimate of the amount of time since the response was |
| generated or validated by the origin server. In essence, the Age |  | generated or validated by the origin server. In essence, the Age |
| value is the sum of the time that the response has been resident in |  | value is the sum of the time that the response has been resident in |
| each of the caches along the path from the origin server, plus the |  | each of the caches along the path from the origin server, plus the |
| amount of time it has been in transit along network paths. |  | amount of time it has been in transit along network paths. |
| The term "age_value" denotes the value of the Age header, in a form |  | The following data is used for the age calculation: |
| appropriate for arithmetic operations. |  |  |
| HTTP/1.1 requires origin servers to send a Date header, if possible, |  | age_value |
| with every response, giving the time at which the response was |  |  |
| generated (see Section 9.3 of [Part1]). The term "date_value" |  |  |
| denotes the value of the Date header, in a form appropriate for |  |  |
| arithmetic operations. |  |  |
| The term "now" means "the current value of the clock at the host |  | The term "age_value" denotes the value of the Age header |
| performing the calculation." Hosts that use HTTP, but especially |  | (Section 3.1), in a form appropriate for arithmetic operation; or |
| hosts running origin servers and caches, SHOULD use NTP [RFC1305] or |  | 0, if not available. |
| some similar protocol to synchronize their clocks to a globally |  |  |
| accurate time standard. |  |  |
| A response's age can be calculated in two entirely independent ways: |  | date_value |
| 1. now minus date_value, if the local clock is reasonably well |  | HTTP/1.1 requires origin servers to send a Date header, if |
| synchronized to the origin server's clock. If the result is |  | possible, with every response, giving the time at which the |
| negative, the result is replaced by zero. |  | response was generated. The term "date_value" denotes the value |
|  |  | of the Date header, in a form appropriate for arithmetic |
|  |  | operations. See Section 9.3 of [Part1] for the definition of the |
|  |  | Date header, and for requirements regarding responses without a |
|  |  | Date response header. |
| 2. age_value, if all of the caches along the response path implement |  | now |
| HTTP/1.1. |  |  |
| These are combined as |  | The term "now" means "the current value of the clock at the host |
|  |  | performing the calculation". Hosts that use HTTP, but especially |
|  |  | hosts running origin servers and caches, SHOULD use NTP |
|  |  | ([RFC1305]) or some similar protocol to synchronize their clocks |
|  |  | to a globally accurate time standard. |
| corrected_received_age = max(now - date_value, age_value) |  | request_time |
| When an Age value is received, it MUST be interpreted relative to the |  | The current value of the clock at the host at the time the request |
| time the request was initiated, not the time that the response was |  | resulting in the stored response was made. |
| received. |  |  |
| corrected_initial_age = corrected_received_age |  | response_time |
| + (now - request_time) |  |  |
| where "request_time" is the time (according to the local clock) when |  | The current value of the clock at the host at the time the |
| the request that elicited this response was sent. |  | response was received. |
| The current_age of a stored response can then be calculated by adding |  | A response's age can be calculated in two entirely independent ways: |
| the amount of time (in seconds) since the stored response was last |  |  |
| validated by the origin server to the corrected_initial_age. |  |  |
| In summary: |  | 1. the "apparent_age": response_time minus date_value, if the local |
|  |  | clock is reasonably well synchronized to the origin server's |
|  |  | clock. If the result is negative, the result is replaced by |
|  |  | zero. |
| age_value - Age header field-value received with the response |  | 2. the "corrected_age_value", if all of the caches along the |
| date_value - Date header field-value received with the response |  | response path implement HTTP/1.1; note this value MUST be |
| request_time - local time when the cache made the request |  | interpreted relative to the time the request was initiated, not |
| resulting in the stored response |  | the time that the response was received. |
| response_time - local time when the cache received the response |  |  |
| now - current local time |  |  |
| apparent_age = max(0, response_time - date_value); |  | apparent_age = max(0, response_time - date_value); |
| corrected_received_age = max(apparent_age, age_value); |  |  |
| response_delay = response_time - request_time; |  | response_delay = response_time - request_time; |
| corrected_initial_age = corrected_received_age + response_delay; |  | corrected_age_value = age_value + response_delay; |
|  |  | These are combined as |
|  |  | corrected_initial_age = max(apparent_age, corrected_age_value); |
|  |  | 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 |
|  |  | 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; |
| 2.3.3. Serving Stale Responses |  | 2.3.3. Serving Stale Responses |
| A "stale" response is one that either has explicit expiry |  | A "stale" response is one that either has explicit expiry information |
| information, or is allowed to have heuristic expiry calculated, but |  | or is allowed to have heuristic expiry calculated, but is not fresh |
| is not fresh according to the calculations in Section 2.3. |  | according to the calculations in Section 2.3. |
| Caches MUST NOT return a stale response if it is prohibited by an |  | Caches 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). |
| Caches SHOULD NOT return stale responses unless they are disconnected |  | Caches SHOULD NOT return stale responses unless they are 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 otherwise explicitly allowed (e.g., the max-stale |  | forward path) or otherwise explicitly allowed (e.g., the max-stale |
| skipping to change at page 14, line 14 |  | skipping to change at page 14, line 17 |
| 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 SHOULD forward it to the requesting client without adding a |
| new Warning (but without removing any existing Warning headers). A |  | new Warning (but without removing any existing Warning headers). A |
| cache SHOULD NOT attempt to validate a response simply because that |  | cache SHOULD NOT attempt to validate a response simply because that |
| response became stale in transit. |  | 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.6), 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, the cache SHOULD add an If- |  | When sending such a conditional request, the cache SHOULD add an If- |
| Modified-Since header whose value is that of the Last-Modified header |  | Modified-Since header whose value is that of the Last-Modified header |
| from the selected (see Section 2.6) stored response, if available. |  | from the selected (see Section 2.7) stored response, if available. |
| Additionally, the cache SHOULD add an If-None-Match header whose |  | Additionally, the cache SHOULD add an If-None-Match header whose |
| value is that of the ETag header(s) from all responses stored for the |  | value is that of the ETag header(s) from all responses stored for the |
| requested URI, if present. However, if any of the stored responses |  | requested URI, if present. However, if any of the stored responses |
| contains only partial content, its entity-tag SHOULD NOT be included |  | contains only partial content, its entity-tag SHOULD NOT be included |
| in the If-None-Match header field unless the request is for a range |  | in the If-None-Match header field unless the request is for a range |
| that would be fully satisfied by that stored response. |  | that would be fully satisfied by that stored response. |
| A 304 (Not Modified) response status code indicates that the stored |  | A 304 (Not Modified) response status code indicates that the stored |
| response can be updated and reused; see Section 2.7. |  | response can be updated and reused; see Section 2.8. |
| A full response (i.e., one with a response body) indicates that none |  | A full response (i.e., one with a response body) indicates that none |
| 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. [[TODO-req-missing: Should |  | request and replace the stored response. [[TODO-req-missing: Should |
| there be a requirement here?]] |  | there be a 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). |
| 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- |  | Effective Request URI (Section 4.3 of [Part1]) as well as the URI(s) |
| Location headers (if present): |  | in the Location and Content-Location headers (if present): |
| o PUT |  | o PUT |
| 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 Effective Request URI (Section 4.3 of |
| service attacks. |  | [Part1]). This helps prevent denial of service attacks. |
| [[TODO-def-host-part: "host part" needs to be specified better.]] |  | [[TODO-def-host-part: "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 Effective Request URI (Section 4.3 |
|  |  | of [Part1]). |
| 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 Effective Request URI, or will mark these as |
| and in need of a mandatory validation before they can be returned in |  | "invalid" and in need of a mandatory validation before they can be |
| 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 |
| 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. |
| [[TODO-spec-success-invalidate: specify that only successful (2xx, |  | [[TODO-spec-success-invalidate: specify that only successful (2xx, |
| 3xx?) responses invalidate.]] |  | 3xx?) responses invalidate.]] |
| 2.6. Caching Negotiated Responses |  | 2.6. Shared Caching of Authenticated Responses |
|  |  | Shared caches MUST NOT use a cached response to a request with an |
|  |  | Authorization header (Section 3.1 of [Part7]) to satisfy any |
|  |  | subsequent request unless a cache directive that allows such |
|  |  | responses to be stored is present in the response. |
|  |  | In this specification, the following Cache-Control response |
|  |  | directives (Section 3.2.2) have such an effect: must-revalidate, |
|  |  | public, s-maxage. |
|  |  | Note that cached responses that contain the "must-revalidate" and/or |
|  |  | "s-maxage" response directives are not allowed to be served stale |
|  |  | (Section 2.3.3) by shared caches. In particular, a response with |
|  |  | either "max-age=0, must-revalidate" or "s-maxage=0" cannot be used to |
|  |  | satisfy a subsequent request without revalidating it on the origin |
|  |  | server. |
|  |  | 2.7. 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 those in the first request can be transformed to those |  | if and only if those in the first request can be transformed to those |
| in the second request by applying any of the following: |  | in the second request by applying any of the following: |
| skipping to change at page 16, line 29 |  | skipping to change at page 16, line 47 |
| 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. |
| If no selected response is available, the cache MAY forward the |  | If no selected response is available, the cache MAY 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.7. Combining Responses |  | 2.8. 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. [[TODO-mention-CL: may need language about Content- |  | response to use. [[TODO-mention-CL: may need language about Content- |
| Location here]][[TODO-inm-mult-etags: cover case where INM with |  | Location here]][[TODO-inm-mult-etags: cover case where INM with |
| skipping to change at page 18, line 9 |  | skipping to change at page 18, line 27 |
| 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 "Cache-Control" general-header field 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 for caches along the request/response chain. Such cache |
| response chain. Such cache directives are unidirectional in that the |  | directives are unidirectional in that the presence of a directive in |
| presence of a directive in a request does not imply that the same |  | a request does not imply that the same directive is to be given in |
| directive is to be given in the response. |  | the response. |
| Note that HTTP/1.0 caches might not implement Cache-Control and |  | HTTP/1.1 caches MUST obey the requirements of the Cache-Control |
| might only implement Pragma: no-cache (see Section 3.4). |  | directives defined in this section. See Section 3.2.3 for |
|  |  | information about how Cache-Control directives defined elsewhere are |
|  |  | handled. |
|  |  | Note: HTTP/1.0 caches might not implement Cache-Control and 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. |
| Cache-Control = "Cache-Control" ":" OWS Cache-Control-v |  | Cache-Control = "Cache-Control" ":" OWS Cache-Control-v |
| Cache-Control-v = 1#cache-directive |  | Cache-Control-v = 1#cache-directive |
| skipping to change at page 19, line 21 |  | skipping to change at page 19, line 44 |
| This directive is NOT a reliable or sufficient mechanism for |  | This directive is NOT a reliable or sufficient mechanism for |
| ensuring privacy. In particular, malicious or compromised caches |  | ensuring privacy. In particular, malicious or compromised caches |
| might not recognize or obey this directive, and communications |  | might not recognize or obey this directive, and communications |
| networks may be vulnerable to eavesdropping. |  | networks may be vulnerable to eavesdropping. |
| max-age |  | max-age |
| The max-age request directive indicates that the client is willing |  | The max-age request directive indicates that the client is willing |
| to accept a response whose age is no greater than the specified |  | to accept a response whose age is no greater than the specified |
| time in seconds. Unless max-stale directive is also included, the |  | time in seconds. Unless the max-stale request directive is also |
| client is not willing to accept a stale response. |  | present, the 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. [[TODO-staleness: of any staleness? |  | stale response of any age. [[TODO-staleness: of any staleness? |
| skipping to change at page 23, line 31 |  | skipping to change at page 24, line 8 |
| does not understand the community cache-extension, since it will also |  | does not understand the community cache-extension, since it will also |
| see and understand the private directive and thus default to the safe |  | see and understand the private directive and thus default to the safe |
| 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). |
|  |  | The HTTP Cache Directive Registry defines the name space for the |
|  |  | cache directives. |
|  |  | Registrations MUST include the following fields: |
|  |  | o Cache Directive Name |
|  |  | o Pointer to specification text |
|  |  | Values to be added to this name space are subject to IETF review |
|  |  | ([RFC5226], Section 4.1). |
|  |  | The registry itself is maintained at |
|  |  | <http://www.iana.org/assignments/http-cache-directives>. |
| 3.3. Expires |  | 3.3. Expires |
| The "Expires" entity-header field 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. |
| skipping to change at page 25, line 4 |  | skipping to change at page 25, line 43 |
| 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 conveys the set of request-header |  | The "Vary" response-header field conveys the set of request-header |
| fields that were used to select the representation. |  | fields that were used to select the representation. |
| Caches use this information, in part, to determine whether a stored |  | Caches use this information, in part, to determine whether a stored |
| response can be used to satisfy a given request; see Section 2.6. |  | response can be used to satisfy a given request; see Section 2.7. |
| determines, while the response is fresh, whether a cache is permitted |  | determines, while the response is fresh, whether a cache is permitted |
| to use the response to reply to a subsequent request without |  | to use the response to reply to a subsequent request without |
| validation; see Section 2.6. |  | validation; see Section 2.7. |
| 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 28, line 27 |  | skipping to change at page 29, line 22 |
| The freshness model (Section 2.3) does not necessarily apply to |  | The freshness model (Section 2.3) does not necessarily apply to |
| history mechanisms. I.e., a history mechanism can display a previous |  | history mechanisms. I.e., a history mechanism can display a previous |
| representation even if it has expired. |  | representation even if it has expired. |
| This does not prohibit the history mechanism from telling the user |  | This does not prohibit the history mechanism from telling the user |
| that a view might be stale, or from honoring cache directives (e.g., |  | that a view might be stale, or from honoring cache directives (e.g., |
| Cache-Control: no-store). |  | Cache-Control: no-store). |
| 5. IANA Considerations |  | 5. IANA Considerations |
| 5.1. Message Header Registration |  | 5.1. Cache Directive Registry |
|  |  | The registration procedure for HTTP Cache Directives is defined by |
|  |  | Section 3.2.3 of this document. |
|  |  | The HTTP Cache Directive Registry should be created at |
|  |  | <http://www.iana.org/assignments/http-cache-directives> and be |
|  |  | populated with the registrations below: |
|  |  | +------------------------+------------------------------+ |
|  |  | | Cache Directive | Reference | |
|  |  | +------------------------+------------------------------+ |
|  |  | | max-age | Section 3.2.1, Section 3.2.2 | |
|  |  | | max-stale | Section 3.2.1 | |
|  |  | | min-fresh | Section 3.2.1 | |
|  |  | | must-revalidate | Section 3.2.2 | |
|  |  | | no-cache | Section 3.2.1, Section 3.2.2 | |
|  |  | | no-store | Section 3.2.1, Section 3.2.2 | |
|  |  | | no-transform | Section 3.2.1, Section 3.2.2 | |
|  |  | | only-if-cached | Section 3.2.1 | |
|  |  | | private | Section 3.2.2 | |
|  |  | | proxy-revalidate | Section 3.2.2 | |
|  |  | | public | Section 3.2.2 | |
|  |  | | s-maxage | Section 3.2.2 | |
|  |  | | stale-if-error | [RFC5861], Section 4 | |
|  |  | | stale-while-revalidate | [RFC5861], Section 3 | |
|  |  | +------------------------+------------------------------+ |
|  |  | 5.2. Message Header Registration |
| The Message Header Registry located at <http://www.iana.org/ |  | The Message Header Registry located at <http://www.iana.org/ |
| assignments/message-headers/message-header-index.html> should be |  | assignments/message-headers/message-header-index.html> should be |
| updated with the permanent registrations below (see [RFC3864]): |  | updated with the permanent registrations below (see [RFC3864]): |
| +-------------------+----------+----------+-------------+ |  | +-------------------+----------+----------+-------------+ |
| | Header Field Name | Protocol | Status | Reference | |  | | Header Field Name | Protocol | Status | Reference | |
| +-------------------+----------+----------+-------------+ |  | +-------------------+----------+----------+-------------+ |
| | Age | http | standard | Section 3.1 | |  | | Age | http | standard | Section 3.1 | |
| | Cache-Control | http | standard | Section 3.2 | |  | | Cache-Control | http | standard | Section 3.2 | |
| skipping to change at page 29, line 24 |  | skipping to change at page 30, line 48 |
| 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 |
| [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-09 |  | and Message Parsing", draft-ietf-httpbis-p1-messaging-10 |
| (work in progress), March 2010. |  | (work in progress), July 2010. |
| [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-09 (work in |  | Semantics", draft-ietf-httpbis-p2-semantics-10 (work in |
| progress), March 2010. |  | progress), July 2010. |
| [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-09 (work in |  | Requests", draft-ietf-httpbis-p4-conditional-10 (work in |
| progress), March 2010. |  | progress), July 2010. |
| [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-09 (work |  | Partial Responses", draft-ietf-httpbis-p5-range-10 (work |
| in progress), March 2010. |  | in progress), July 2010. |
| [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-09 (work in progress), |  | draft-ietf-httpbis-p7-auth-10 (work in progress), |
| March 2010. |  | July 2010. |
| [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) |
| Specification, Implementation", RFC 1305, March 1992. |  | Specification, Implementation", RFC 1305, March 1992. |
| [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., |  | [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext |  | Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext |
| Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. |  | Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. |
| [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration |  | [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration |
| Procedures for Message Header Fields", BCP 90, RFC 3864, |  | Procedures for Message Header Fields", BCP 90, RFC 3864, |
| September 2004. |  | September 2004. |
|  |  | [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an |
|  |  | IANA Considerations Section in RFCs", BCP 26, RFC 5226, |
|  |  | May 2008. |
|  |  | [RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale |
|  |  | Content", RFC 5861, April 2010. |
| Appendix A. Compatibility with Previous Versions |  | Appendix A. Compatibility with Previous Versions |
| 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). |
| 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.8) |
| 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.8, 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 |
|  |  | Make the specified age calculation algorithm less conservative. |
|  |  | (Section 2.3.2) |
| Remove requirement to consider Content-Location in successful |  | Remove requirement to consider Content-Location in successful |
| responses in order to determine the appropriate response to use. |  | responses in order to determine the appropriate response to use. |
| (Section 2.4) |  | (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 |  | Do not mention RFC 2047 encoding and multiple languages in Warning |
| headers anymore, as these aspects never were implemented. |  | headers anymore, as these aspects never were implemented. |
| (Section 3.6) |  | (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 |
| skipping to change at page 34, line 34 |  | skipping to change at page 36, line 17 |
| C.7. Since draft-ietf-httpbis-p6-cache-05 |  | C.7. Since draft-ietf-httpbis-p6-cache-05 |
| This is a total rewrite of this part of the specification. |  | This is a total rewrite of this part of the specification. |
| Affected issues: |  | Affected issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/54>: "Definition of |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/54>: "Definition of |
| 1xx Warn-Codes" |  | 1xx Warn-Codes" |
| o <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/60>: "Placement |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/60>: "Placement of |
| of 13.5.1 and 13.5.2" |  | 13.5.1 and 13.5.2" |
| o <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/138>: "The role |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/138>: "The role of |
| of Warning and Semantic Transparency in Caching" |  | Warning and Semantic Transparency in Caching" |
| o <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/139>: "Methods |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/139>: "Methods and |
| and Caching" |  | Caching" |
| In addition: Final work on ABNF conversion |  | In addition: Final work on ABNF conversion |
| (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |  | (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |
| o Add appendix containing collected and expanded ABNF, reorganize |  | o Add appendix containing collected and expanded ABNF, reorganize |
| ABNF introduction. |  | ABNF introduction. |
| C.8. Since draft-ietf-httpbis-p6-cache-06 |  | C.8. Since draft-ietf-httpbis-p6-cache-06 |
| Closed issues: |  | Closed issues: |
| skipping to change at page 36, line 5 |  | skipping to change at page 37, line 31 |
| Affected issues: |  | Affected issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/199>: Status codes |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/199>: Status codes |
| and caching |  | and caching |
| Partly resolved issues: |  | Partly resolved issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/60>: "Placement of |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/60>: "Placement of |
| 13.5.1 and 13.5.2" |  | 13.5.1 and 13.5.2" |
|  |  | C.11. Since draft-ietf-httpbis-p6-cache-09 |
|  |  | Closed issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/29>: "Age |
|  |  | calculation" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/168>: "Clarify |
|  |  | differences between / requirements for request and response CC |
|  |  | directives" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/174>: "Caching |
|  |  | authenticated responses" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/208>: "IANA registry |
|  |  | for cache-control directives" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/211>: "Heuristic |
|  |  | caching of URLs with query components" |
|  |  | Partly resolved issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/196>: "Term for the |
|  |  | requested resource's URI" |
| 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, 22 |  | max-age 19, 22 |
| max-stale 19 |  | max-stale 19 |
| min-fresh 19 |  | min-fresh 20 |
| must-revalidate 21 |  | must-revalidate 22 |
| no-cache 18, 21 |  | no-cache 19, 21 |
| no-store 18, 21 |  | no-store 19, 22 |
| no-transform 19, 22 |  | no-transform 20, 23 |
| only-if-cached 19 |  | only-if-cached 20 |
| private 20 |  | private 21 |
| proxy-revalidate 22 |  | proxy-revalidate 22 |
| public 20 |  | public 20 |
| s-maxage 22 |  | s-maxage 22 |
| Cache-Control header 18 |  | Cache-Control header 18 |
| cacheable 5 |  | cacheable 5 |
| E |  | E |
| Expires header 23 |  | Expires header 24 |
| explicit expiration time 5 |  | explicit expiration time 5 |
| F |  | F |
| first-hand 6 |  | first-hand 6 |
| fresh 6 |  | fresh 6 |
| freshness lifetime 6 |  | freshness lifetime 6 |
| G |  | G |
| Grammar |  | Grammar |
| Age 17 |  | Age 18 |
| Age-v 17 |  | Age-v 18 |
| Cache-Control 18 |  | Cache-Control 18 |
| Cache-Control-v 18 |  | Cache-Control-v 18 |
| cache-extension 18 |  | cache-extension 18 |
| cache-request-directive 18 |  | cache-request-directive 19 |
| cache-response-directive 20 |  | cache-response-directive 20 |
| delta-seconds 17 |  | delta-seconds 18 |
| Expires 23 |  | Expires 24 |
| Expires-v 23 |  | Expires-v 24 |
| extension-pragma 24 |  | extension-pragma 25 |
| Pragma 24 |  | Pragma 25 |
| pragma-directive 24 |  | pragma-directive 25 |
| Pragma-v 24 |  | Pragma-v 25 |
| Vary 25 |  | Vary 26 |
| Vary-v 25 |  | Vary-v 26 |
| warn-agent 26 |  | warn-agent 27 |
| warn-code 26 |  | warn-code 27 |
| warn-date 26 |  | warn-date 27 |
| warn-text 26 |  | warn-text 27 |
| Warning 26 |  | Warning 27 |
| Warning-v 26 |  | Warning-v 27 |
| warning-value 26 |  | warning-value 27 |
| H |  | H |
| Headers |  | Headers |
| Age 17 |  | Age 17 |
| Cache-Control 18 |  | Cache-Control 18 |
| Expires 23 |  | Expires 24 |
| Pragma 24 |  | Pragma 25 |
| Vary 24 |  | Vary 25 |
| Warning 25 |  | Warning 26 |
| heuristic expiration time 5 |  | heuristic expiration time 5 |
| M |  | M |
| max-age |  | max-age |
| Cache Directive 19, 22 |  | Cache Directive 19, 22 |
| max-stale |  | max-stale |
| Cache Directive 19 |  | Cache Directive 19 |
| min-fresh |  | min-fresh |
| Cache Directive 19 |  | Cache Directive 20 |
| must-revalidate |  | must-revalidate |
| Cache Directive 21 |  | Cache Directive 22 |
| N |  | N |
| no-cache |  | no-cache |
| Cache Directive 18, 21 |  | Cache Directive 19, 21 |
| no-store |  | no-store |
| Cache Directive 18, 21 |  |  |
| no-transform |  |  |
| Cache Directive 19, 22 |  | Cache Directive 19, 22 |
|  |  | no-transform |
|  |  | Cache Directive 20, 23 |
| O |  | O |
| only-if-cached |  | only-if-cached |
| Cache Directive 19 |  | Cache Directive 20 |
| P |  | P |
| Pragma header 24 |  | Pragma header 25 |
| private |  | private |
| Cache Directive 20 |  | Cache Directive 21 |
| proxy-revalidate |  | proxy-revalidate |
| Cache Directive 22 |  | Cache Directive 22 |
| public |  | public |
| Cache Directive 20 |  | Cache Directive 20 |
| S |  | S |
| s-maxage |  | s-maxage |
| Cache Directive 22 |  | Cache Directive 22 |
| stale 6 |  | stale 6 |
| V |  | V |
| validator 6 |  | validator 6 |
| Vary header 24 |  | Vary header 25 |
| W |  | W |
| Warning header 25 |  | Warning header 26 |
| Authors' Addresses |  | Authors' Addresses |
| Roy T. Fielding (editor) |  | Roy T. Fielding (editor) |
| Day Software |  | Day Software |
| 23 Corporate Plaza DR, Suite 280 |  | 23 Corporate Plaza DR, Suite 280 |
| Newport Beach, CA 92660 |  | Newport Beach, CA 92660 |
| USA |  | USA |
| Phone: +1-949-706-5300 |  | Phone: +1-949-706-5300 |
| Fax: +1-949-706-5305 |  | Fax: +1-949-706-5305 |
| Email: fielding@gbiv.com |  | EMail: fielding@gbiv.com |
| URI: http://roy.gbiv.com/ |  | URI: http://roy.gbiv.com/ |
| Jim Gettys |  | Jim Gettys |
| One Laptop per Child |  | Alcatel-Lucent Bell Labs |
| 21 Oak Knoll Road |  | 21 Oak Knoll Road |
| Carlisle, MA 01741 |  | Carlisle, MA 01741 |
| USA |  | USA |
| Email: jg@laptop.org |  | EMail: jg@freedesktop.org |
| URI: http://www.laptop.org/ |  | URI: http://gettys.wordpress.com/ |
| Jeffrey C. Mogul |  | Jeffrey C. Mogul |
| Hewlett-Packard Company |  | Hewlett-Packard Company |
| HP Labs, Large Scale Systems Group |  | HP Labs, Large Scale Systems Group |
| 1501 Page Mill Road, MS 1177 |  | 1501 Page Mill Road, MS 1177 |
| Palo Alto, CA 94304 |  | Palo Alto, CA 94304 |
| USA |  | USA |
| Email: JeffMogul@acm.org |  | EMail: JeffMogul@acm.org |
| Henrik Frystyk Nielsen |  | Henrik Frystyk Nielsen |
| Microsoft Corporation |  | Microsoft Corporation |
| 1 Microsoft Way |  | 1 Microsoft Way |
| Redmond, WA 98052 |  | Redmond, WA 98052 |
| USA |  | USA |
| Email: henrikn@microsoft.com |  | EMail: henrikn@microsoft.com |
| Larry Masinter |  | Larry Masinter |
| Adobe Systems, Incorporated |  | Adobe Systems, Incorporated |
| 345 Park Ave |  | 345 Park Ave |
| San Jose, CA 95110 |  | San Jose, CA 95110 |
| USA |  | USA |
| Email: LMM@acm.org |  | EMail: LMM@acm.org |
| URI: http://larry.masinter.net/ |  | URI: http://larry.masinter.net/ |
| Paul J. Leach |  | Paul J. Leach |
| Microsoft Corporation |  | Microsoft Corporation |
| 1 Microsoft Way |  | 1 Microsoft Way |
| Redmond, WA 98052 |  | Redmond, WA 98052 |
| Email: paulle@microsoft.com |  | EMail: paulle@microsoft.com |
| Tim Berners-Lee |  | Tim Berners-Lee |
| World Wide Web Consortium |  | World Wide Web Consortium |
| MIT Computer Science and Artificial Intelligence Laboratory |  | MIT Computer Science and Artificial Intelligence Laboratory |
| The Stata Center, Building 32 |  | The Stata Center, Building 32 |
| 32 Vassar Street |  | 32 Vassar Street |
| Cambridge, MA 02139 |  | Cambridge, MA 02139 |
| USA |  | USA |
| Email: timbl@w3.org |  | EMail: timbl@w3.org |
| URI: http://www.w3.org/People/Berners-Lee/ |  | URI: http://www.w3.org/People/Berners-Lee/ |
| Yves Lafon (editor) |  | Yves Lafon (editor) |
| 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) |
| 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 |
| Phone: +49 251 2807760 |  | Phone: +49 251 2807760 |
| Fax: +49 251 2807761 |  | Fax: +49 251 2807761 |
| Email: julian.reschke@greenbytes.de |  | EMail: julian.reschke@greenbytes.de |
| URI: http://greenbytes.de/tech/webdav/ |  | URI: http://greenbytes.de/tech/webdav/ |
End of changes. 97 change blocks.
| 210 lines changed or deleted |  | 314 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/