| draft-ietf-httpbis-p6-cache-24.txt |  | draft-ietf-httpbis-p6-cache-25.txt |
--- | --- | --- | --- | ---
| HTTPbis Working Group R. Fielding, Ed. |  | HTTPbis Working Group R. Fielding, Ed. |
| Internet-Draft Adobe |  | Internet-Draft Adobe |
| Obsoletes: 2616 (if approved) M. Nottingham, Ed. |  | Obsoletes: 2616 (if approved) M. Nottingham, Ed. |
| Intended status: Standards Track Akamai |  | Intended status: Standards Track Akamai |
| Expires: March 29, 2014 J. Reschke, Ed. |  | Expires: May 21, 2014 J. Reschke, Ed. |
| greenbytes |  | greenbytes |
| September 25, 2013 |  | November 17, 2013 |
| Hypertext Transfer Protocol (HTTP/1.1): Caching |  | Hypertext Transfer Protocol (HTTP/1.1): Caching |
| draft-ietf-httpbis-p6-cache-24 |  | draft-ietf-httpbis-p6-cache-25 |
| Abstract |  | Abstract |
| The Hypertext Transfer Protocol (HTTP) is an application-level |  | The Hypertext Transfer Protocol (HTTP) is an application-level |
| protocol for distributed, collaborative, hypertext information |  | protocol for distributed, collaborative, hypertext information |
| systems. This document defines requirements on HTTP caches and the |  | systems. This document defines requirements on HTTP caches and the |
| associated header fields that control cache behavior or indicate |  | associated header fields that control cache behavior or indicate |
| cacheable response messages. |  | cacheable response messages. |
| Editorial Note (To be removed by RFC Editor) |  | Editorial Note (To be removed by RFC Editor) |
| Discussion of this draft takes place on the HTTPBIS working group |  | Discussion of this draft takes place on the HTTPBIS working group |
| mailing list (ietf-http-wg@w3.org), which is archived at |  | mailing list (ietf-http-wg@w3.org), which is archived at |
| <http://lists.w3.org/Archives/Public/ietf-http-wg/>. |  | <http://lists.w3.org/Archives/Public/ietf-http-wg/>. |
| The current issues list is at |  | The current issues list is at |
| <http://tools.ietf.org/wg/httpbis/trac/report/3> and related |  | <http://tools.ietf.org/wg/httpbis/trac/report/3> and related |
| documents (including fancy diffs) can be found at |  | documents (including fancy diffs) can be found at |
| <http://tools.ietf.org/wg/httpbis/>. |  | <http://tools.ietf.org/wg/httpbis/>. |
| The changes in this draft are summarized in Appendix D.5. |  | The changes in this draft are summarized in Appendix D.1. |
| Status of This Memo |  | Status of This Memo |
| This Internet-Draft is submitted in full conformance with the |  | This Internet-Draft is submitted in full conformance with the |
| provisions of BCP 78 and BCP 79. |  | provisions of BCP 78 and BCP 79. |
| Internet-Drafts are working documents of the Internet Engineering |  | Internet-Drafts are working documents of the Internet Engineering |
| Task Force (IETF). Note that other groups may also distribute |  | Task Force (IETF). Note that other groups may also distribute |
| working documents as Internet-Drafts. The list of current Internet- |  | working documents as Internet-Drafts. The list of current Internet- |
| Drafts is at http://datatracker.ietf.org/drafts/current/. |  | Drafts is at http://datatracker.ietf.org/drafts/current/. |
| Internet-Drafts are draft documents valid for a maximum of six months |  | Internet-Drafts are draft documents valid for a maximum of six months |
| and may be updated, replaced, or obsoleted by other documents at any |  | and may be updated, replaced, or obsoleted by other documents at any |
| time. It is inappropriate to use Internet-Drafts as reference |  | time. It is inappropriate to use Internet-Drafts as reference |
| material or to cite them other than as "work in progress." |  | material or to cite them other than as "work in progress." |
| This Internet-Draft will expire on March 29, 2014. |  | This Internet-Draft will expire on May 21, 2014. |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2013 IETF Trust and the persons identified as the |  | Copyright (c) 2013 IETF Trust and the persons identified as the |
| document authors. All rights reserved. |  | document authors. All rights reserved. |
| This document is subject to BCP 78 and the IETF Trust's Legal |  | This document is subject to BCP 78 and the IETF Trust's Legal |
| Provisions Relating to IETF Documents |  | Provisions Relating to IETF Documents |
| (http://trustee.ietf.org/license-info) in effect on the date of |  | (http://trustee.ietf.org/license-info) in effect on the date of |
| publication of this document. Please review these documents |  | publication of this document. Please review these documents |
| skipping to change at page 2, line 43 |  | skipping to change at page 2, line 43 |
| Table of Contents |  | Table of Contents |
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 |  | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 |
| 1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4 |  | 1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4 |
| 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 |  | 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 |
| 1.2.1. Delta Seconds . . . . . . . . . . . . . . . . . . . . 5 |  | 1.2.1. Delta Seconds . . . . . . . . . . . . . . . . . . . . 5 |
| 2. Overview of Cache Operation . . . . . . . . . . . . . . . . . 5 |  | 2. Overview of Cache Operation . . . . . . . . . . . . . . . . . 5 |
| 3. Storing Responses in Caches . . . . . . . . . . . . . . . . . 6 |  | 3. Storing Responses in Caches . . . . . . . . . . . . . . . . . 6 |
| 3.1. Storing Incomplete Responses . . . . . . . . . . . . . . . 7 |  | 3.1. Storing Incomplete Responses . . . . . . . . . . . . . . . 7 |
| 3.2. Storing Responses to Authenticated Requests . . . . . . . 7 |  | 3.2. Storing Responses to Authenticated Requests . . . . . . . 7 |
| 3.3. Combining Partial Content . . . . . . . . . . . . . . . . 7 |  | 3.3. Combining Partial Content . . . . . . . . . . . . . . . . 8 |
| 4. Constructing Responses from Caches . . . . . . . . . . . . . . 8 |  | 4. Constructing Responses from Caches . . . . . . . . . . . . . . 8 |
| 4.1. Calculating Secondary Keys with Vary . . . . . . . . . . . 9 |  | 4.1. Calculating Secondary Keys with Vary . . . . . . . . . . . 9 |
| 4.2. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 10 |  | 4.2. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 10 |
| 4.2.1. Calculating Freshness Lifetime . . . . . . . . . . . . 12 |  | 4.2.1. Calculating Freshness Lifetime . . . . . . . . . . . . 12 |
| 4.2.2. Calculating Heuristic Freshness . . . . . . . . . . . 12 |  | 4.2.2. Calculating Heuristic Freshness . . . . . . . . . . . 12 |
| 4.2.3. Calculating Age . . . . . . . . . . . . . . . . . . . 13 |  | 4.2.3. Calculating Age . . . . . . . . . . . . . . . . . . . 13 |
| 4.2.4. Serving Stale Responses . . . . . . . . . . . . . . . 14 |  | 4.2.4. Serving Stale Responses . . . . . . . . . . . . . . . 15 |
| 4.3. Validation . . . . . . . . . . . . . . . . . . . . . . . . 15 |  | 4.3. Validation . . . . . . . . . . . . . . . . . . . . . . . . 15 |
| 4.3.1. Sending a Validation Request . . . . . . . . . . . . . 15 |  | 4.3.1. Sending a Validation Request . . . . . . . . . . . . . 15 |
| 4.3.2. Handling a Received Validation Request . . . . . . . . 16 |  | 4.3.2. Handling a Received Validation Request . . . . . . . . 16 |
| 4.3.3. Handling a Validation Response . . . . . . . . . . . . 17 |  | 4.3.3. Handling a Validation Response . . . . . . . . . . . . 17 |
| 4.3.4. Freshening Stored Responses upon Validation . . . . . 18 |  | 4.3.4. Freshening Stored Responses upon Validation . . . . . 18 |
| 4.3.5. Freshening Responses via HEAD . . . . . . . . . . . . 18 |  | 4.3.5. Freshening Responses via HEAD . . . . . . . . . . . . 19 |
| 4.4. Invalidation . . . . . . . . . . . . . . . . . . . . . . . 19 |  | 4.4. Invalidation . . . . . . . . . . . . . . . . . . . . . . . 19 |
| 5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 20 |  | 5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 20 |
| 5.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 |  | 5.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 |
| 5.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 20 |  | 5.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 21 |
| 5.2.1. Request Cache-Control Directives . . . . . . . . . . . 21 |  | 5.2.1. Request Cache-Control Directives . . . . . . . . . . . 21 |
| 5.2.2. Response Cache-Control Directives . . . . . . . . . . 23 |  | 5.2.2. Response Cache-Control Directives . . . . . . . . . . 23 |
| 5.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 26 |  | 5.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 26 |
| 5.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 27 |  | 5.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 27 |
| 5.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 28 |  | 5.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 28 |
| 5.5. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 29 |  | 5.5. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 29 |
| 5.5.1. Warning: 110 - "Response is Stale" . . . . . . . . . . 30 |  | 5.5.1. Warning: 110 - "Response is Stale" . . . . . . . . . . 31 |
| 5.5.2. Warning: 111 - "Revalidation Failed" . . . . . . . . . 31 |  | 5.5.2. Warning: 111 - "Revalidation Failed" . . . . . . . . . 31 |
| 5.5.3. Warning: 112 - "Disconnected Operation" . . . . . . . 31 |  | 5.5.3. Warning: 112 - "Disconnected Operation" . . . . . . . 31 |
| 5.5.4. Warning: 113 - "Heuristic Expiration" . . . . . . . . 31 |  | 5.5.4. Warning: 113 - "Heuristic Expiration" . . . . . . . . 31 |
| 5.5.5. Warning: 199 - "Miscellaneous Warning" . . . . . . . . 31 |  | 5.5.5. Warning: 199 - "Miscellaneous Warning" . . . . . . . . 31 |
| 5.5.6. Warning: 214 - "Transformation Applied" . . . . . . . 31 |  | 5.5.6. Warning: 214 - "Transformation Applied" . . . . . . . 31 |
| 5.5.7. Warning: 299 - "Miscellaneous Persistent Warning" . . 31 |  | 5.5.7. Warning: 299 - "Miscellaneous Persistent Warning" . . 31 |
| 6. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 31 |  | 6. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 31 |
| 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 |  | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 |
| 7.1. Cache Directive Registry . . . . . . . . . . . . . . . . . 32 |  | 7.1. Cache Directive Registry . . . . . . . . . . . . . . . . . 32 |
| 7.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 32 |  | 7.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 32 |
| 7.1.2. Considerations for New Cache Control Directives . . . 32 |  | 7.1.2. Considerations for New Cache Control Directives . . . 32 |
| 7.1.3. Registrations . . . . . . . . . . . . . . . . . . . . 32 |  | 7.1.3. Registrations . . . . . . . . . . . . . . . . . . . . 33 |
| 7.2. Warn Code Registry . . . . . . . . . . . . . . . . . . . . 33 |  | 7.2. Warn Code Registry . . . . . . . . . . . . . . . . . . . . 33 |
| 7.2.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 33 |  | 7.2.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 33 |
| 7.2.2. Registrations . . . . . . . . . . . . . . . . . . . . 33 |  | 7.2.2. Registrations . . . . . . . . . . . . . . . . . . . . 33 |
| 7.3. Header Field Registration . . . . . . . . . . . . . . . . 34 |  | 7.3. Header Field Registration . . . . . . . . . . . . . . . . 34 |
| 8. Security Considerations . . . . . . . . . . . . . . . . . . . 34 |  | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 34 |
| 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 |  | 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 |
| 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 |  | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 |
| 10.1. Normative References . . . . . . . . . . . . . . . . . . . 35 |  | 10.1. Normative References . . . . . . . . . . . . . . . . . . . 35 |
| 10.2. Informative References . . . . . . . . . . . . . . . . . . 36 |  | 10.2. Informative References . . . . . . . . . . . . . . . . . . 36 |
| Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 36 |  | Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 36 |
| Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 38 |  | Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 38 |
| Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 38 |  | Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 38 |
| Appendix D. Change Log (to be removed by RFC Editor before |  | Appendix D. Change Log (to be removed by RFC Editor before |
| publication) . . . . . . . . . . . . . . . . . . . . 39 |  | publication) . . . . . . . . . . . . . . . . . . . . 39 |
| D.1. Since draft-ietf-httpbis-p6-cache-19 . . . . . . . . . . . 40 |  | D.1. Since draft-ietf-httpbis-p6-cache-24 . . . . . . . . . . . 40 |
| D.2. Since draft-ietf-httpbis-p6-cache-20 . . . . . . . . . . . 40 |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 |
| D.3. Since draft-ietf-httpbis-p6-cache-21 . . . . . . . . . . . 41 |  |  |
| D.4. Since draft-ietf-httpbis-p6-cache-22 . . . . . . . . . . . 41 |  |  |
| D.5. Since draft-ietf-httpbis-p6-cache-23 . . . . . . . . . . . 41 |  |  |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 |  |  |
| 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. |
| An HTTP cache is a local store of response messages and the subsystem |  | An HTTP cache is a local store of response messages and the subsystem |
| that controls storage, retrieval, and deletion of messages in it. A |  | that controls storage, retrieval, and deletion of messages in it. A |
| skipping to change at page 5, line 12 |  | skipping to change at page 5, line 12 |
| documents. Appendix C shows the collected ABNF with the list rule |  | documents. Appendix C shows the collected ABNF with the list rule |
| expanded. |  | expanded. |
| 1.2.1. Delta Seconds |  | 1.2.1. Delta Seconds |
| The delta-seconds rule specifies a non-negative integer, representing |  | The delta-seconds rule specifies a non-negative integer, representing |
| time in seconds. |  | time in seconds. |
| delta-seconds = 1*DIGIT |  | delta-seconds = 1*DIGIT |
| If a cache receives a delta-seconds value larger than the largest |  | A recipient parsing a delta-seconds value and converting it to binary |
| positive integer it can represent, or if any of its subsequent |  | form ought to use an arithmetic type of at least 31 bits of non- |
| calculations overflows, the cache MUST consider the value to be |  | negative integer range. If a cache receives a delta-seconds value |
| 2147483648 (2^31). A recipient parsing a delta-seconds value MUST |  | greater than the greatest integer it can represent, or if any of its |
| use an arithmetic type of at least 31 bits of range, and a sender |  | subsequent calculations overflows, the cache MUST consider the value |
| MUST NOT generate delta-seconds with a value greater than 2147483648. |  | to be either 2147483648 (2^31) or the greatest positive integer it |
|  |  | can conveniently represent. |
|  |  | Note: The value 2147483648 is here for historical reasons, |
|  |  | effectively represents infinity (over 68 years), and does not need |
|  |  | to be stored in binary form; an implementation could produce it as |
|  |  | a canned string if any overflow occurs, even if the calculations |
|  |  | are performed with an arithmetic type incapable of directly |
|  |  | representing that number. What matters here is that an overflow |
|  |  | be detected and not treated as a negative value in later |
|  |  | calculations. |
| 2. Overview of Cache Operation |  | 2. Overview of Cache Operation |
| Proper cache operation preserves the semantics of HTTP transfers |  | Proper cache operation preserves the semantics of HTTP transfers |
| ([Part2]) while eliminating the transfer of information already held |  | ([Part2]) while eliminating the transfer of information already held |
| in the cache. Although caching is an entirely OPTIONAL feature of |  | in the cache. Although caching is an entirely OPTIONAL feature of |
| HTTP, we assume that reusing the cached response is desirable and |  | HTTP, we assume that reusing the cached response is desirable and |
| that such reuse is the default behavior when no requirement or local |  | that such reuse is the default behavior when no requirement or local |
| configuration prevents it. Therefore, HTTP cache requirements are |  | configuration prevents it. Therefore, HTTP cache requirements are |
| focused on preventing a cache from either storing a non-reusable |  | focused on preventing a cache from either storing a non-reusable |
| skipping to change at page 6, line 37 |  | skipping to change at page 6, line 46 |
| * contains a max-age response cache directive (see |  | * contains a max-age response cache directive (see |
| Section 5.2.2.8), or |  | Section 5.2.2.8), or |
| * contains a s-maxage response cache directive (see |  | * contains a s-maxage response cache directive (see |
| Section 5.2.2.9) and the cache is shared, or |  | Section 5.2.2.9) and the cache is shared, or |
| * contains a Cache Control Extension (see Section 5.2.3) that |  | * contains a Cache Control Extension (see Section 5.2.3) that |
| allows it to be cached, or |  | allows it to be cached, or |
| * has a status code that is defined as cacheable (see |  | * has a status code that is defined as cacheable by default (see |
| Section 4.2.2), or |  | Section 4.2.2), or |
| * contains a public response cache directive (see |  | * contains a public response cache directive (see |
| Section 5.2.2.5). |  | Section 5.2.2.5). |
| Note that any of the requirements listed above can be overridden by a |  | Note that any of the requirements listed above can be overridden by a |
| cache-control extension; see Section 5.2.3. |  | cache-control extension; see Section 5.2.3. |
| In this context, a cache has "understood" a request method or a |  | In this context, a cache has "understood" a request method or a |
| response status code if it recognizes it and implements all specified |  | response status code if it recognizes it and implements all specified |
| skipping to change at page 12, line 45 |  | skipping to change at page 13, line 4 |
| a cache MAY assign a heuristic expiration time when an explicit time |  | a cache MAY assign a heuristic expiration time when an explicit time |
| is not specified, employing algorithms that use other header field |  | is not specified, employing algorithms that use other header field |
| values (such as the Last-Modified time) to estimate a plausible |  | values (such as the Last-Modified time) to estimate a plausible |
| expiration time. This specification does not provide specific |  | expiration time. This specification does not provide specific |
| algorithms, but does impose worst-case constraints on their results. |  | algorithms, but does impose worst-case constraints on their results. |
| A cache MUST NOT use heuristics to determine freshness when an |  | A cache MUST NOT use heuristics to determine freshness when an |
| explicit expiration time is present in the stored response. Because |  | explicit expiration time is present in the stored response. Because |
| of the requirements in Section 3, this means that, effectively, |  | of the requirements in Section 3, this means that, effectively, |
| heuristics can only be used on responses without explicit freshness |  | heuristics can only be used on responses without explicit freshness |
| whose status codes are defined as cacheable, and responses without |  | whose status codes are defined as cacheable by default (see Section |
| explicit freshness that have been marked as explicitly cacheable |  | 6.1 of [Part2]), and those responses without explicit freshness that |
| (e.g., with a "public" response cache directive). |  | have been marked as explicitly cacheable (e.g., with a "public" |
|  |  | response cache directive). |
| If the response has a Last-Modified header field (Section 2.2 of |  | If the response has a Last-Modified header field (Section 2.2 of |
| [Part4]), caches are encouraged to use a heuristic expiration value |  | [Part4]), caches are encouraged to use a heuristic expiration value |
| that is no more than some fraction of the interval since that time. |  | that is no more than some fraction of the interval since that time. |
| A typical setting of this fraction might be 10%. |  | A typical setting of this fraction might be 10%. |
| When a heuristic is used to calculate freshness lifetime, a cache |  | When a heuristic is used to calculate freshness lifetime, a cache |
| SHOULD generate a Warning header field with a 113 warn-code (see |  | SHOULD generate a Warning header field with a 113 warn-code (see |
| Section 5.5.4) in the response if its current_age is more than 24 |  | Section 5.5.4) in the response if its current_age is more than 24 |
| hours and such a warning is not already present. |  | hours and such a warning is not already present. |
| skipping to change at page 13, line 45 |  | skipping to change at page 14, line 8 |
| date_value |  | date_value |
| The term "date_value" denotes the value of the Date header field, |  | The term "date_value" denotes the value of the Date header field, |
| in a form appropriate for arithmetic operations. See Section |  | in a form appropriate for arithmetic operations. See Section |
| 7.1.1.2 of [Part2] for the definition of the Date header field, |  | 7.1.1.2 of [Part2] for the definition of the Date header field, |
| and for requirements regarding responses without it. |  | and for requirements regarding responses without it. |
| now |  | now |
| The term "now" means "the current value of the clock at the host |  | The term "now" means "the current value of the clock at the host |
| performing the calculation". A host ought to use NTP ([RFC1305]) |  | performing the calculation". A host ought to use NTP ([RFC5905]) |
| or some similar protocol to synchronize its clocks to Coordinated |  | or some similar protocol to synchronize its clocks to Coordinated |
| Universal Time. |  | Universal Time. |
| request_time |  | request_time |
| The current value of the clock at the host at the time the request |  | The current value of the clock at the host at the time the request |
| resulting in the stored response was made. |  | resulting in the stored response was made. |
| response_time |  | response_time |
| skipping to change at page 21, line 42 |  | skipping to change at page 21, line 52 |
| Argument syntax: |  | Argument syntax: |
| delta-seconds (see Section 1.2.1) |  | delta-seconds (see Section 1.2.1) |
| The "max-age" request directive indicates that the client is |  | The "max-age" request directive indicates that the client is |
| unwilling to accept a response whose age is greater than the |  | unwilling to accept a response whose age is greater than the |
| specified number of seconds. Unless the max-stale request directive |  | specified number of seconds. Unless the max-stale request directive |
| is also present, the client is not willing to accept a stale |  | is also present, the client is not willing to accept a stale |
| response. |  | response. |
| Note: This directive uses the token form of the argument syntax; |  | This directive uses the token form of the argument syntax; e.g., |
| e.g., 'max-age=5', not 'max-age="5"'. A sender SHOULD NOT generate |  | 'max-age=5', not 'max-age="5"'. A sender SHOULD NOT generate the |
| the quoted-string form. |  | quoted-string form. |
| 5.2.1.2. max-stale |  | 5.2.1.2. max-stale |
| Argument syntax: |  | Argument syntax: |
| delta-seconds (see Section 1.2.1) |  | delta-seconds (see Section 1.2.1) |
| 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 freshness |  | willing to accept a response that has exceeded its freshness |
| lifetime. If max-stale is assigned a value, then the client is |  | lifetime. If max-stale is assigned a value, then the client is |
| willing to accept a response that has exceeded its freshness lifetime |  | willing to accept a response that has exceeded its freshness lifetime |
| 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 stale |  | assigned to max-stale, then the client is willing to accept a stale |
| response of any age. |  | response of any age. |
| Note: This directive uses the token form of the argument syntax; |  | This directive uses the token form of the argument syntax; e.g., |
| e.g., 'max-stale=10', not 'max-stale="10"'. A sender SHOULD NOT |  | 'max-stale=10', not 'max-stale="10"'. A sender SHOULD NOT generate |
| generate the quoted-string form. |  | the quoted-string form. |
| 5.2.1.3. min-fresh |  | 5.2.1.3. min-fresh |
| Argument syntax: |  | Argument syntax: |
| delta-seconds (see Section 1.2.1) |  | delta-seconds (see Section 1.2.1) |
| 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 than |  | willing to accept a response whose freshness lifetime is no less than |
| its current age plus the specified time in seconds. That is, the |  | 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. |  | specified number of seconds. |
| Note: This directive uses the token form of the argument syntax; |  | This directive uses the token form of the argument syntax; e.g., |
| e.g., 'min-fresh=20', not 'min-fresh="20"'. A sender SHOULD NOT |  | 'min-fresh=20', not 'min-fresh="20"'. A sender SHOULD NOT generate |
| generate the quoted-string form. |  | the quoted-string form. |
| 5.2.1.4. no-cache |  | 5.2.1.4. no-cache |
| The "no-cache" request directive indicates that a cache MUST NOT use |  | The "no-cache" request directive indicates that a cache MUST NOT use |
| a stored response to satisfy the request without successful |  | a stored response to satisfy the request without successful |
| validation on the origin server. |  | validation on the origin server. |
| 5.2.1.5. no-store |  | 5.2.1.5. no-store |
| The "no-store" request directive indicates that a cache MUST NOT |  | The "no-store" request directive indicates that a cache MUST NOT |
| skipping to change at page 24, line 19 |  | skipping to change at page 24, line 29 |
| subject to any other restrictions on caching. However, any header |  | subject to any other restrictions on caching. However, any header |
| fields in the response that have the field-name(s) listed MUST NOT be |  | fields in the response that have the field-name(s) listed MUST NOT be |
| sent in the response to a subsequent request without successful |  | sent in the response to a subsequent request without successful |
| revalidation with the origin server. This allows an origin server to |  | revalidation with the origin server. This allows an origin server to |
| prevent the re-use of certain header fields in a response, while |  | prevent the re-use of certain header fields in a response, while |
| still allowing caching of the rest of the response. |  | still allowing caching of the rest of the response. |
| The field-names given are not limited to the set of header fields |  | The field-names given are not limited to the set of header fields |
| defined by this specification. Field names are case-insensitive. |  | defined by this specification. Field names are case-insensitive. |
|  |  | This directive uses the quoted-string form of the argument syntax. A |
|  |  | sender SHOULD NOT generate the token form (even if quoting appears |
|  |  | not to be needed for single-entry lists). |
| Note: Although it has been back-ported to many implementations, some |  | Note: Although it has been back-ported to many implementations, some |
| HTTP/1.0 caches will not recognize or obey this directive. Also, no- |  | HTTP/1.0 caches will not recognize or obey this directive. Also, no- |
| cache response directives with field-names are often handled by |  | cache response directives with field-names are often handled by |
| caches as if an unqualified no-cache directive was received; i.e., |  | caches as if an unqualified no-cache directive was received; i.e., |
| the special handling for the qualified form is not widely |  | the special handling for the qualified form is not widely |
| implemented. |  | implemented. |
| Note: This directive uses the quoted-string form of the argument |  |  |
| syntax. A sender SHOULD NOT generate the token form (even if quoting |  |  |
| appears not to be needed for single-entry lists). |  |  |
| 5.2.2.3. no-store |  | 5.2.2.3. 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 private and shared caches. "MUST NOT |  | directive applies to both private 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 best- |  | store the information in non-volatile storage, and MUST make a best- |
| effort attempt to remove the information from volatile storage as |  | effort attempt to remove the information from volatile storage as |
| promptly as possible after forwarding it. |  | promptly as possible after forwarding it. |
| skipping to change at page 25, line 13 |  | skipping to change at page 25, line 20 |
| payload, as defined in Section 5.7.2 of [Part1]. |  | payload, as defined in Section 5.7.2 of [Part1]. |
| 5.2.2.5. public |  | 5.2.2.5. public |
| The "public" response directive indicates that any cache MAY store |  | The "public" response directive indicates that any cache MAY store |
| the response, even if the response would normally be non-cacheable or |  | the response, even if the response would normally be non-cacheable or |
| cacheable only within a private cache. (See Section 3.2 for |  | cacheable only within a private cache. (See Section 3.2 for |
| additional details related to the use of public in response to a |  | additional details related to the use of public in response to a |
| request containing Authorization, and Section 3 for details of how |  | request containing Authorization, and Section 3 for details of how |
| public affects responses that would normally not be stored, due to |  | public affects responses that would normally not be stored, due to |
| their status codes not being defined as cacheable.) |  | their status codes not being defined as cacheable by default; see |
|  |  | Section 4.2.2.) |
| 5.2.2.6. private |  | 5.2.2.6. private |
| Argument syntax: |  | Argument syntax: |
| #field-name |  | #field-name |
| The "private" response directive indicates that the response message |  | The "private" response directive indicates that the response message |
| is intended for a single user and MUST NOT be stored by a shared |  | is intended for a single user and MUST NOT be stored by a shared |
| cache. A private cache MAY store the response and reuse it for later |  | cache. A private cache MAY store the response and reuse it for later |
| skipping to change at page 25, line 35 |  | skipping to change at page 25, line 43 |
| If the private response directive specifies one or more field-names, |  | If the private response directive specifies one or more field-names, |
| this requirement is limited to the field-values associated with the |  | this requirement is limited to the field-values associated with the |
| listed response header fields. That is, a shared cache MUST NOT |  | listed response header fields. That is, a shared cache MUST NOT |
| store the specified field-names(s), whereas it MAY store the |  | store the specified field-names(s), whereas it MAY store the |
| remainder of the response message. |  | remainder of the response message. |
| The field-names given are not limited to the set of header fields |  | The field-names given are not limited to the set of header fields |
| defined by this specification. Field names are case-insensitive. |  | defined by this specification. Field names are case-insensitive. |
|  |  | This directive uses the quoted-string form of the argument syntax. A |
|  |  | sender SHOULD NOT generate the token form (even if quoting appears |
|  |  | not to be needed for single-entry lists). |
| Note: This usage of the word "private" only controls where the |  | Note: This usage of the word "private" only controls where the |
| response can be stored; it cannot ensure the privacy of the message |  | response can be stored; it cannot ensure the privacy of the message |
| content. Also, private response directives with field-names are |  | content. Also, private response directives with field-names are |
| often handled by caches as if an unqualified private directive was |  | often handled by caches as if an unqualified private directive was |
| received; i.e., the special handling for the qualified form is not |  | received; i.e., the special handling for the qualified form is not |
| widely implemented. |  | widely implemented. |
| Note: This directive uses the quoted-string form of the argument |  |  |
| syntax. A sender SHOULD NOT generate the token form (even if quoting |  |  |
| appears not to be needed for single-entry lists). |  |  |
| 5.2.2.7. proxy-revalidate |  | 5.2.2.7. proxy-revalidate |
| The "proxy-revalidate" response directive has the same meaning as the |  | The "proxy-revalidate" response directive has the same meaning as the |
| must-revalidate response directive, except that it does not apply to |  | must-revalidate response directive, except that it does not apply to |
| private caches. |  | private caches. |
| 5.2.2.8. max-age |  | 5.2.2.8. max-age |
| Argument syntax: |  | Argument syntax: |
| delta-seconds (see Section 1.2.1) |  | delta-seconds (see Section 1.2.1) |
| The "max-age" response directive indicates that the response is to be |  | The "max-age" response directive indicates that the response is to be |
| considered stale after its age is greater than the specified number |  | considered stale after its age is greater than the specified number |
| of seconds. |  | of seconds. |
| Note: This directive uses the token form of the argument syntax; |  | This directive uses the token form of the argument syntax; e.g., |
| e.g., 'max-age=5', not 'max-age="5"'. A sender SHOULD NOT generate |  | 'max-age=5', not 'max-age="5"'. A sender SHOULD NOT generate the |
| the quoted-string form. |  | quoted-string form. |
| 5.2.2.9. s-maxage |  | 5.2.2.9. s-maxage |
| Argument syntax: |  | Argument syntax: |
| delta-seconds (see Section 1.2.1) |  | delta-seconds (see Section 1.2.1) |
| The "s-maxage" response directive indicates that, in shared caches, |  | The "s-maxage" response directive indicates that, in shared caches, |
| the maximum age specified by this directive overrides the maximum age |  | the maximum age specified by this directive overrides the maximum age |
| specified by either the max-age directive or the Expires header |  | specified by either the max-age directive or the Expires header |
| field. The s-maxage directive also implies the semantics of the |  | field. The s-maxage directive also implies the semantics of the |
| proxy-revalidate response directive. |  | proxy-revalidate response directive. |
| Note: This directive uses the token form of the argument syntax; |  | This directive uses the token form of the argument syntax; e.g., |
| e.g., 's-maxage=10', not 's-maxage="10"'. A sender SHOULD NOT |  | 's-maxage=10', not 's-maxage="10"'. A sender SHOULD NOT generate the |
| generate the quoted-string form. |  | quoted-string form. |
| 5.2.3. Cache Control Extensions |  | 5.2.3. Cache Control Extensions |
| The Cache-Control header field can be extended through the use of one |  | The Cache-Control header field can be extended through the use of one |
| or more cache-extension tokens, each with an optional value. |  | or more cache-extension tokens, each with an optional value. |
| Informational extensions (those that do not require a change in cache |  | Informational extensions (those that do not require a change in cache |
| behavior) can be added without changing the semantics of other |  | behavior) can be added without changing the semantics of other |
| directives. Behavioral extensions are designed to work by acting as |  | directives. Behavioral extensions are designed to work by acting as |
| modifiers to the existing base of cache directives. |  | modifiers to the existing base of cache directives. |
| skipping to change at page 32, line 12 |  | skipping to change at page 32, line 18 |
| 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). |
| 7. IANA Considerations |  | 7. IANA Considerations |
| 7.1. Cache Directive Registry |  | 7.1. Cache Directive Registry |
| The HTTP Cache Directive Registry defines the name space for the |  | The HTTP Cache Directive Registry defines the name space for the |
| cache directives. It will be created and maintained at |  | cache directives. It will be created and maintained at (the |
|  |  | suggested URI) |
| <http://www.iana.org/assignments/http-cache-directives>. |  | <http://www.iana.org/assignments/http-cache-directives>. |
| 7.1.1. Procedure |  | 7.1.1. Procedure |
| A registration MUST include the following fields: |  | A registration MUST include the following fields: |
| o Cache Directive Name |  | o Cache Directive Name |
| o Pointer to specification text |  | o Pointer to specification text |
| skipping to change at page 33, line 27 |  | skipping to change at page 33, line 32 |
| | proxy-revalidate | Section 5.2.2.7 | |  | | proxy-revalidate | Section 5.2.2.7 | |
| | public | Section 5.2.2.5 | |  | | public | Section 5.2.2.5 | |
| | s-maxage | Section 5.2.2.9 | |  | | s-maxage | Section 5.2.2.9 | |
| | stale-if-error | [RFC5861], Section 4 | |  | | stale-if-error | [RFC5861], Section 4 | |
| | stale-while-revalidate | [RFC5861], Section 3 | |  | | stale-while-revalidate | [RFC5861], Section 3 | |
| +------------------------+----------------------------------+ |  | +------------------------+----------------------------------+ |
| 7.2. Warn Code Registry |  | 7.2. Warn Code Registry |
| The HTTP Warn Code Registry defines the name space for warn codes. |  | The HTTP Warn Code Registry defines the name space for warn codes. |
| It will be created and maintained at |  | It will be created and maintained at (the suggested URI) |
| <http://www.iana.org/assignments/http-warn-codes>. |  | <http://www.iana.org/assignments/http-warn-codes>. |
| 7.2.1. Procedure |  | 7.2.1. Procedure |
| A registration MUST include the following fields: |  | A registration MUST include the following fields: |
| o Warn Code (3 digits) |  | o Warn Code (3 digits) |
| o Short Description |  | o Short Description |
| skipping to change at page 35, line 38 |  | skipping to change at page 35, line 38 |
| 9. Acknowledgments |  | 9. Acknowledgments |
| See Section 10 of [Part1]. |  | See Section 10 of [Part1]. |
| 10. References |  | 10. References |
| 10.1. Normative References |  | 10.1. Normative References |
| [Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |  | [Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |
| Protocol (HTTP/1.1): Message Syntax and Routing", |  | Protocol (HTTP/1.1): Message Syntax and Routing", |
| draft-ietf-httpbis-p1-messaging-24 (work in progress), |  | draft-ietf-httpbis-p1-messaging-25 (work in progress), |
| September 2013. |  | November 2013. |
| [Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |  | [Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |
| Protocol (HTTP/1.1): Semantics and Content", |  | Protocol (HTTP/1.1): Semantics and Content", |
| draft-ietf-httpbis-p2-semantics-24 (work in progress), |  | draft-ietf-httpbis-p2-semantics-25 (work in progress), |
| September 2013. |  | November 2013. |
| [Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |  | [Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |
| Protocol (HTTP/1.1): Conditional Requests", |  | Protocol (HTTP/1.1): Conditional Requests", |
| draft-ietf-httpbis-p4-conditional-24 (work in progress), |  | draft-ietf-httpbis-p4-conditional-25 (work in progress), |
| September 2013. |  | November 2013. |
| [Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |  | [Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |
| "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", |  | "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", |
| draft-ietf-httpbis-p5-range-24 (work in progress), |  | draft-ietf-httpbis-p5-range-25 (work in progress), |
| September 2013. |  | November 2013. |
| [Part7] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |  | [Part7] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |
| Protocol (HTTP/1.1): Authentication", |  | Protocol (HTTP/1.1): Authentication", |
| draft-ietf-httpbis-p7-auth-24 (work in progress), |  | draft-ietf-httpbis-p7-auth-25 (work in progress), |
| September 2013. |  | November 2013. |
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |  | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |
| Requirement Levels", BCP 14, RFC 2119, March 1997. |  | Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax |  | [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax |
| Specifications: ABNF", STD 68, RFC 5234, January 2008. |  | Specifications: ABNF", STD 68, RFC 5234, January 2008. |
| 10.2. Informative References |  | 10.2. Informative References |
| [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration |  | [BCP90] 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. |
| [RFC1305] Mills, D., "Network Time Protocol (Version 3) |  |  |
| 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. |
| [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an |  | [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an |
| IANA Considerations Section in RFCs", BCP 26, RFC 5226, |  | IANA Considerations Section in RFCs", BCP 26, RFC 5226, |
| May 2008. |  | May 2008. |
| [RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale |  | [RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale |
| Content", RFC 5861, April 2010. |  | Content", RFC 5861, April 2010. |
|  |  | [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, |
|  |  | "Network Time Protocol Version 4: Protocol and Algorithms |
|  |  | Specification", RFC 5905, June 2010. |
| [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, |  | [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, |
| April 2011. |  | April 2011. |
| Appendix A. Changes from RFC 2616 |  | Appendix A. Changes from RFC 2616 |
| The specification has been substantially rewritten for clarity. |  | The specification has been substantially rewritten for clarity. |
| The conditions under which an authenticated response can be cached |  | The conditions under which an authenticated response can be cached |
| have been clarified. (Section 3.2) |  | have been clarified. (Section 3.2) |
| skipping to change at page 39, line 49 |  | skipping to change at page 39, line 49 |
| warn-agent = ( uri-host [ ":" port ] ) / pseudonym |  | warn-agent = ( uri-host [ ":" port ] ) / pseudonym |
| warn-code = 3DIGIT |  | warn-code = 3DIGIT |
| warn-date = DQUOTE HTTP-date DQUOTE |  | warn-date = DQUOTE HTTP-date DQUOTE |
| warn-text = quoted-string |  | warn-text = quoted-string |
| warning-value = warn-code SP warn-agent SP warn-text [ SP warn-date |  | warning-value = warn-code SP warn-agent SP warn-text [ SP warn-date |
| ] |  | ] |
| Appendix D. Change Log (to be removed by RFC Editor before publication) |  | Appendix D. Change Log (to be removed by RFC Editor before publication) |
| Changes up to the first Working Group Last Call draft are summarized |  | Changes up to the IETF Last Call draft are summarized in <http:// |
| in <http://trac.tools.ietf.org/html/ |  | trac.tools.ietf.org/html/draft-ietf-httpbis-p6-cache-24#appendix-D>. |
| draft-ietf-httpbis-p6-cache-19#appendix-C>. |  |  |
| D.1. Since draft-ietf-httpbis-p6-cache-19 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/307>: "untangle |  |  |
| Cache-Control ABNF" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/353>: "Multiple |  |  |
| values in Cache-Control header fields" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/355>: "Case |  |  |
| sensitivity of header fields in CC values" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/356>: "Spurious |  |  |
| 'MAYs'" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/360>: "enhance |  |  |
| considerations for new cache control directives" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/361>: "ABNF |  |  |
| requirements for recipients" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/368>: "note |  |  |
| introduction of new IANA registries as normative changes" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/373>: "broken prose |  |  |
| in description of 'Vary'" |  |  |
| D.2. Since draft-ietf-httpbis-p6-cache-20 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/375>: "'Most |  |  |
| Conservative'" |  |  |
| Other changes: |  |  |
| o Conformance criteria and considerations regarding error handling |  |  |
| are now defined in Part 1. |  |  |
| o Move definition of "Vary" header field into Part 2. |  |  |
| o Add security considerations with respect to cache poisoning and |  |  |
| the "Set-Cookie" header field. |  |  |
| D.3. Since draft-ietf-httpbis-p6-cache-21 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/223>: "Allowing |  |  |
| heuristic caching for new status codes" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/406>: "304 without |  |  |
| validator" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/418>: "No-Transform" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/430>: "Revert prior |  |  |
| change to the meaning of the public cache response directive. |  |  |
| D.4. Since draft-ietf-httpbis-p6-cache-22 |  | D.1. Since draft-ietf-httpbis-p6-cache-24 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/436>: "explain list |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/499>: "RFC 1305 ref |
| expansion in ABNF appendices" |  | needs to be updated to 5905" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/453>: "Returning the |  |  |
| freshest response" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/464>: "placement of |  |  |
| extension point considerations" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/469>: "Editorial |  |  |
| notes for p6" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/471>: "Vary and |  |  |
| future requests" |  |  |
| D.5. Since draft-ietf-httpbis-p6-cache-23 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/486>: "Requiring |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/500>: "dangling |
| proxies to process warn-date" |  | reference to cacheable status codes" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/496>: "add Warning |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/512>: "APPSDIR |
| header field examples" |  | review of draft-ietf-httpbis-p6-cache-24" |
| Index |  | Index |
| 1 |  | 1 |
| 110 (warn-code) 30 |  | 110 (warn-code) 31 |
| 111 (warn-code) 31 |  | 111 (warn-code) 31 |
| 112 (warn-code) 31 |  | 112 (warn-code) 31 |
| 113 (warn-code) 31 |  | 113 (warn-code) 31 |
| 199 (warn-code) 31 |  | 199 (warn-code) 31 |
| 2 |  | 2 |
| 214 (warn-code) 31 |  | 214 (warn-code) 31 |
| 299 (warn-code) 31 |  | 299 (warn-code) 31 |
| A |  | A |
| age 10 |  | age 10 |
| Age header field 20 |  | Age header field 20 |
| C |  | C |
| cache 4 |  | cache 4 |
| cache entry 5 |  | cache entry 5 |
| cache key 5 |  | cache key 5 |
| Cache-Control header field 20 |  | Cache-Control header field 21 |
| D |  | D |
| Disconnected Operation (warn-text) 31 |  | Disconnected Operation (warn-text) 31 |
| E |  | E |
| Expires header field 27 |  | Expires header field 27 |
| explicit expiration time 10 |  | explicit expiration time 10 |
| F |  | F |
| fresh 10 |  | fresh 10 |
| skipping to change at page 43, line 9 |  | skipping to change at page 41, line 26 |
| warn-text 29 |  | warn-text 29 |
| Warning 29 |  | Warning 29 |
| warning-value 29 |  | warning-value 29 |
| H |  | H |
| Heuristic Expiration (warn-text) 31 |  | Heuristic Expiration (warn-text) 31 |
| heuristic expiration time 10 |  | heuristic expiration time 10 |
| M |  | M |
| max-age (cache directive) 21, 26 |  | max-age (cache directive) 21, 26 |
| max-stale (cache directive) 21 |  | max-stale (cache directive) 22 |
| min-fresh (cache directive) 22 |  | min-fresh (cache directive) 22 |
| Miscellaneous Persistent Warning (warn-text) 31 |  | Miscellaneous Persistent Warning (warn-text) 31 |
| Miscellaneous Warning (warn-text) 31 |  | Miscellaneous Warning (warn-text) 31 |
| must-revalidate (cache directive) 23 |  | must-revalidate (cache directive) 23 |
| N |  | N |
| no-cache (cache directive) 22-23 |  | no-cache (cache directive) 22, 24 |
| no-store (cache directive) 22, 24 |  | no-store (cache directive) 22, 24 |
| no-transform (cache directive) 23-24 |  | no-transform (cache directive) 23, 25 |
| O |  | O |
| only-if-cached (cache directive) 23 |  | only-if-cached (cache directive) 23 |
| P |  | P |
| Pragma header field 28 |  | Pragma header field 28 |
| private (cache directive) 25 |  | private (cache directive) 25 |
| private cache 4 |  | private cache 4 |
| proxy-revalidate (cache directive) 25 |  | proxy-revalidate (cache directive) 26 |
| public (cache directive) 25 |  | public (cache directive) 25 |
| R |  | R |
| Response is Stale (warn-text) 30 |  | Response is Stale (warn-text) 31 |
| Revalidation Failed (warn-text) 31 |  | Revalidation Failed (warn-text) 31 |
| S |  | S |
| s-maxage (cache directive) 26 |  | s-maxage (cache directive) 26 |
| shared cache 4 |  | shared cache 4 |
| stale 10 |  | stale 10 |
| strong validator 18 |  | strong validator 18 |
| T |  | T |
| Transformation Applied (warn-text) 31 |  | Transformation Applied (warn-text) 31 |
End of changes. 47 change blocks.
| 160 lines changed or deleted |  | 93 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/