| draft-ietf-httpbis-p6-cache-25.txt |  | draft-ietf-httpbis-p6-cache-26.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: May 21, 2014 J. Reschke, Ed. |  | Expires: August 10, 2014 J. Reschke, Ed. |
| greenbytes |  | greenbytes |
| November 17, 2013 |  | February 6, 2014 |
| Hypertext Transfer Protocol (HTTP/1.1): Caching |  | Hypertext Transfer Protocol (HTTP/1.1): Caching |
| draft-ietf-httpbis-p6-cache-25 |  | draft-ietf-httpbis-p6-cache-26 |
| Abstract |  | Abstract |
| The Hypertext Transfer Protocol (HTTP) is an application-level |  | The Hypertext Transfer Protocol (HTTP) is a stateless application- |
| protocol for distributed, collaborative, hypertext information |  | level protocol for distributed, collaborative, hypertext information |
| systems. This document defines requirements on HTTP caches and the |  | systems. This document defines HTTP caches and the associated header |
| associated header fields that control cache behavior or indicate |  | fields that control cache behavior or indicate cacheable response |
| cacheable response messages. |  | messages. |
| Editorial Note (To be removed by RFC Editor) |  | Editorial Note (To be removed by RFC Editor) |
| Discussion of this draft takes place on the HTTPBIS working group |  | Discussion of this draft takes place on the HTTPBIS working group |
| mailing list (ietf-http-wg@w3.org), which is archived at |  | mailing list (ietf-http-wg@w3.org), which is archived at |
| <http://lists.w3.org/Archives/Public/ietf-http-wg/>. |  | <http://lists.w3.org/Archives/Public/ietf-http-wg/>. |
| The current issues list is at |  | The current issues list is at |
| <http://tools.ietf.org/wg/httpbis/trac/report/3> and related |  | <http://tools.ietf.org/wg/httpbis/trac/report/3> and related |
| documents (including fancy diffs) can be found at |  | documents (including fancy diffs) can be found at |
| <http://tools.ietf.org/wg/httpbis/>. |  | <http://tools.ietf.org/wg/httpbis/>. |
| The changes in this draft are summarized in Appendix D.1. |  | The changes in this draft are summarized in Appendix D.2. |
| Status of This Memo |  | Status of This Memo |
| This Internet-Draft is submitted in full conformance with the |  | This Internet-Draft is submitted in full conformance with the |
| provisions of BCP 78 and BCP 79. |  | provisions of BCP 78 and BCP 79. |
| Internet-Drafts are working documents of the Internet Engineering |  | Internet-Drafts are working documents of the Internet Engineering |
| Task Force (IETF). Note that other groups may also distribute |  | Task Force (IETF). Note that other groups may also distribute |
| working documents as Internet-Drafts. The list of current Internet- |  | working documents as Internet-Drafts. The list of current Internet- |
| Drafts is at http://datatracker.ietf.org/drafts/current/. |  | Drafts is at http://datatracker.ietf.org/drafts/current/. |
| Internet-Drafts are draft documents valid for a maximum of six months |  | Internet-Drafts are draft documents valid for a maximum of six months |
| and may be updated, replaced, or obsoleted by other documents at any |  | and may be updated, replaced, or obsoleted by other documents at any |
| time. It is inappropriate to use Internet-Drafts as reference |  | time. It is inappropriate to use Internet-Drafts as reference |
| material or to cite them other than as "work in progress." |  | material or to cite them other than as "work in progress." |
| This Internet-Draft will expire on May 21, 2014. |  | This Internet-Draft will expire on August 10, 2014. |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2013 IETF Trust and the persons identified as the |  | Copyright (c) 2014 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 |
| skipping to change at page 3, line 19 |  | skipping to change at page 3, line 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 . . . . . . . . . . . . . . . . . . . . . . 21 |  | 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" . . . . . . . . . . 31 |  | 5.5.1. Warning: 110 - "Response is Stale" . . . . . . . . . . 30 |
| 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 . . . . . . . . . . . . . . . . . . . . 33 |  | 7.1.3. Registrations . . . . . . . . . . . . . . . . . . . . 32 |
| 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-24 . . . . . . . . . . . 40 |  | D.1. Since draft-ietf-httpbis-p6-cache-24 . . . . . . . . . . . 40 |
|  |  | D.2. Since draft-ietf-httpbis-p6-cache-25 . . . . . . . . . . . 40 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 |
| 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 |
| cache stores cacheable responses in order to reduce the response time |  | cache stores cacheable responses in order to reduce the response time |
| and network bandwidth consumption on future, equivalent requests. |  | and network bandwidth consumption on future, equivalent requests. |
| Any client or server MAY employ a cache, though a cache cannot be |  | Any client or server MAY employ a cache, though a cache cannot be |
| used by a server that is acting as a tunnel. |  | used by a server that is acting as a tunnel. |
| A shared cache is a cache that stores responses to be reused by more |  | A shared cache is a cache that stores responses to be reused by more |
| than one user; shared caches are usually (but not always) deployed as |  | than one user; shared caches are usually (but not always) deployed as |
| a part of an intermediary. A private cache, in contrast, is |  | a part of an intermediary. A private cache, in contrast, is |
| dedicated to a single user. |  | dedicated to a single user; often, they are deployed as a component |
|  |  | of a user agent. |
| The goal of caching in HTTP/1.1 is to significantly improve |  | The goal of caching in HTTP/1.1 is to significantly improve |
| performance by reusing a prior response message to satisfy a current |  | performance by reusing a prior response message to satisfy a current |
| request. A stored response is considered "fresh", as defined in |  | request. A stored response is considered "fresh", as defined in |
| Section 4.2, if the response can be reused without "validation" |  | Section 4.2, if the response can be reused without "validation" |
| (checking with the origin server to see if the cached response |  | (checking with the origin server to see if the cached response |
| remains valid for this request). A fresh response can therefore |  | remains valid for this request). A fresh response can therefore |
| reduce both latency and network overhead each time it is reused. |  | reduce both latency and network overhead each time it is reused. |
| When a cached response is not fresh, it might still be reusable if it |  | When a cached response is not fresh, it might still be reusable if it |
| can be freshened by validation (Section 4.3) or if the origin is |  | can be freshened by validation (Section 4.3) or if the origin is |
| skipping to change at page 4, line 47 |  | skipping to change at page 4, line 48 |
| 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]. |
| Conformance criteria and considerations regarding error handling are |  | Conformance criteria and considerations regarding error handling are |
| defined in Section 2.5 of [Part1]. |  | defined in Section 2.5 of [Part1]. |
| 1.2. Syntax Notation |  | 1.2. Syntax Notation |
| This specification uses the Augmented Backus-Naur Form (ABNF) |  | This specification uses the Augmented Backus-Naur Form (ABNF) |
| notation of [RFC5234] with the list rule extension defined in Section |  | notation of [RFC5234] with a list extension, defined in Section 7 of |
| 7 of [Part1]. Appendix B describes rules imported from other |  | [Part1], that allows for compact definition of comma-separated lists |
| documents. Appendix C shows the collected ABNF with the list rule |  | using a '#' operator (similar to how the '*' operator indicates |
| expanded. |  | repetition). Appendix B describes rules imported from other |
|  |  | documents. Appendix C shows the collected grammar with all list |
|  |  | operators expanded to standard ABNF notation. |
| 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 |
| A recipient parsing a delta-seconds value and converting it to binary |  | A recipient parsing a delta-seconds value and converting it to binary |
| form ought to use an arithmetic type of at least 31 bits of non- |  | form ought to use an arithmetic type of at least 31 bits of non- |
| skipping to change at page 5, line 34 |  | skipping to change at page 5, line 35 |
| are performed with an arithmetic type incapable of directly |  | are performed with an arithmetic type incapable of directly |
| representing that number. What matters here is that an overflow |  | representing that number. What matters here is that an overflow |
| be detected and not treated as a negative value in later |  | be detected and not treated as a negative value in later |
| calculations. |  | 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, it can be assumed that reusing a cached response is desirable |
| that such reuse is the default behavior when no requirement or local |  | and that such reuse is the default behavior when no requirement or |
| configuration prevents it. Therefore, HTTP cache requirements are |  | local configuration prevents it. Therefore, HTTP cache requirements |
| focused on preventing a cache from either storing a non-reusable |  | are focused on preventing a cache from either storing a non-reusable |
| response or reusing a stored response inappropriately, rather than |  | response or reusing a stored response inappropriately, rather than |
| mandating that caches always store and reuse particular responses. |  | mandating that caches always store and reuse particular responses. |
| Each cache entry consists of a cache key and one or more HTTP |  | Each cache entry consists of a cache key and one or more HTTP |
| responses corresponding to prior requests that used the same key. |  | responses corresponding to prior requests that used the same key. |
| The most common form of cache entry is a successful result of a |  | The most common form of cache entry is a successful result of a |
| retrieval request: i.e., a 200 (OK) response to a GET request, which |  | retrieval request: i.e., a 200 (OK) response to a GET request, which |
| contains a representation of the resource identified by the request |  | contains a representation of the resource identified by the request |
| target (Section 4.3.1 of [Part2]). However, it is also possible to |  | target (Section 4.3.1 of [Part2]). However, it is also possible to |
| cache permanent redirects, negative results (e.g., 404 (Not Found)), |  | cache permanent redirects, negative results (e.g., 404 (Not Found)), |
| skipping to change at page 6, line 26 |  | skipping to change at page 6, line 27 |
| A cache MUST NOT store a response to any request, unless: |  | A cache MUST NOT store a response to any request, unless: |
| o The request method is understood by the cache and defined as being |  | o The request method is understood by the cache and defined as being |
| cacheable, and |  | cacheable, and |
| 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 5.2) does not appear |  | o the "no-store" cache directive (see Section 5.2) does not appear |
| in request or response header fields, and |  | in request or response header fields, and |
| o the "private" cache response directive (see Section 5.2.2.6) does |  | o the "private" response directive (see Section 5.2.2.6) does not |
| 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 field (see Section 4.1 of [Part7]) does |  | o the Authorization header field (see Section 4.2 of [Part7]) does |
| not appear in the request, if the cache is shared, unless the |  | not appear in the request, if the cache is shared, unless the |
| response explicitly allows it (see Section 3.2), and |  | response explicitly allows it (see Section 3.2), and |
| o the response either: |  | o the response either: |
| * contains an Expires header field (see Section 5.3), or |  | * contains an Expires header field (see Section 5.3), or |
| * contains a max-age response cache directive (see |  | * contains a max-age response 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 directive (see Section 5.2.2.9) |
| Section 5.2.2.9) and the cache is shared, or |  | 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 by default (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 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 |
| caching-related behavior. |  | caching-related behavior. |
| Note that, in normal operation, some caches will not store a response |  | Note that, in normal operation, some caches will not store a response |
| that has neither a cache validator nor an explicit expiration time, |  | that has neither a cache validator nor an explicit expiration time, |
| skipping to change at page 7, line 41 |  | skipping to change at page 7, line 40 |
| response with the stored entry, as defined in Section 3.3. A cache |  | response with the stored entry, as defined in Section 3.3. A cache |
| MUST NOT use an incomplete response to answer requests unless the |  | MUST NOT use an incomplete response to answer requests unless the |
| response has been made complete or the request is partial and |  | response has been made complete or the request is partial and |
| specifies a range that is wholly within the incomplete response. A |  | specifies a range that is wholly within the incomplete response. A |
| cache MUST NOT send a partial response to a client without explicitly |  | cache MUST NOT send a partial response to a client without explicitly |
| marking it as such using the 206 (Partial Content) status code. |  | marking it as such using the 206 (Partial Content) status code. |
| 3.2. Storing Responses to Authenticated Requests |  | 3.2. Storing Responses to Authenticated Requests |
| A shared cache MUST NOT use a cached response to a request with an |  | A shared cache MUST NOT use a cached response to a request with an |
| Authorization header field (Section 4.1 of [Part7]) to satisfy any |  | Authorization header field (Section 4.2 of [Part7]) to satisfy any |
| subsequent request unless a cache directive that allows such |  | subsequent request unless a cache directive that allows such |
| responses to be stored is present in the response. |  | responses to be stored is present in the response. |
| In this specification, the following Cache-Control response |  | In this specification, the following Cache-Control response |
| directives (Section 5.2.2) have such an effect: must-revalidate, |  | directives (Section 5.2.2) have such an effect: must-revalidate, |
| public, s-maxage. |  | public, s-maxage. |
| Note that cached responses that contain the "must-revalidate" and/or |  | Note that cached responses that contain the "must-revalidate" and/or |
| "s-maxage" response directives are not allowed to be served stale |  | "s-maxage" response directives are not allowed to be served stale |
| (Section 4.2.4) by shared caches. In particular, a response with |  | (Section 4.2.4) by shared caches. In particular, a response with |
| skipping to change at page 11, line 12 |  | skipping to change at page 11, line 8 |
| A response's age is the time that has passed since it was generated |  | A response's age is the time that has passed since it was generated |
| by, or successfully validated with, the origin server. |  | by, or successfully validated with, the origin server. |
| 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 field (Section 5.3) or the max-age response |  | either the Expires header field (Section 5.3) or the max-age response |
| cache directive (Section 5.2.2.8). Generally, origin servers will |  | directive (Section 5.2.2.8). Generally, origin servers will assign |
| assign future explicit expiration times to responses in the belief |  | future explicit expiration times to responses in the belief that the |
| that the representation is not likely to change in a semantically |  | representation is not likely to change in a semantically significant |
| significant way before the expiration time is reached. |  | way before the expiration time is reached. |
| If an origin server wishes to force a cache to validate every |  | If an origin server wishes to force a cache to validate every |
| request, it can assign an explicit expiration time in the past to |  | request, it can assign an explicit expiration time in the past to |
| indicate that the response is already stale. Compliant caches will |  | indicate that the response is already stale. Compliant caches will |
| normally validate a stale cached response before reusing it for |  | normally validate a stale cached response before reusing it for |
| subsequent requests (see Section 4.2.4). |  | subsequent requests (see Section 4.2.4). |
| Since origin servers do not always provide explicit expiration times, |  | Since origin servers do not always provide explicit expiration times, |
| caches are also allowed to use a heuristic to determine an expiration |  | caches are also allowed to use a heuristic to determine an expiration |
| time under certain circumstances (see Section 4.2.2). |  | time under certain circumstances (see Section 4.2.2). |
| skipping to change at page 12, line 18 |  | skipping to change at page 12, line 12 |
| Note that freshness applies only to cache operation; it cannot be |  | Note that freshness applies only to cache operation; it cannot be |
| used to force a user agent to refresh its display or reload a |  | used to force a user agent to refresh its display or reload a |
| resource. See Section 6 for an explanation of the difference between |  | resource. See Section 6 for an explanation of the difference between |
| caches and history mechanisms. |  | caches and history mechanisms. |
| 4.2.1. Calculating Freshness Lifetime |  | 4.2.1. Calculating Freshness Lifetime |
| A cache can calculate the freshness lifetime (denoted as |  | A cache can calculate the freshness lifetime (denoted as |
| freshness_lifetime) of a response by using the first match of: |  | freshness_lifetime) of a response by using the first match of: |
| o If the cache is shared and the s-maxage response cache directive |  | o If the cache is shared and the s-maxage response directive |
| (Section 5.2.2.9) is present, use its value, or |  | (Section 5.2.2.9) is present, use its value, or |
| o If the max-age response cache directive (Section 5.2.2.8) is |  | o If the max-age response directive (Section 5.2.2.8) is present, |
| present, use its value, or |  | use its value, or |
| o If the Expires response header field (Section 5.3) is present, use |  | o If the Expires response header field (Section 5.3) is present, use |
| its value minus the value of the Date response header field, or |  | its value minus the value of the Date response header field, or |
| o Otherwise, no explicit expiration time is present in the response. |  | o Otherwise, no explicit expiration time is present in the response. |
| A heuristic freshness lifetime might be applicable; see |  | A heuristic freshness lifetime might be applicable; see |
| Section 4.2.2. |  | Section 4.2.2. |
| 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. |
| skipping to change at page 13, line 7 |  | skipping to change at page 12, line 50 |
| 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 by default (see Section |  | whose status codes are defined as cacheable by default (see Section |
| 6.1 of [Part2]), and those responses without explicit freshness that |  | 6.1 of [Part2]), and those responses without explicit freshness that |
| have been marked as explicitly cacheable (e.g., with a "public" |  | have been marked as explicitly cacheable (e.g., with a "public" |
| response cache directive). |  | response 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 19, line 25 |  | skipping to change at page 19, line 25 |
| When a cache makes an inbound HEAD request for a given request target |  | When a cache makes an inbound HEAD request for a given request target |
| and receives a 200 (OK) response, the cache SHOULD update or |  | and receives a 200 (OK) response, the cache SHOULD update or |
| invalidate each of its stored GET responses that could have been |  | invalidate each of its stored GET responses that could have been |
| selected for that request (see Section 4.1). |  | selected for that request (see Section 4.1). |
| For each of the stored responses that could have been selected, if |  | For each of the stored responses that could have been selected, if |
| the stored response and HEAD response have matching values for any |  | the stored response and HEAD response have matching values for any |
| received validator fields (ETag and Last-Modified) and, if the HEAD |  | received validator fields (ETag and Last-Modified) and, if the HEAD |
| response has a Content-Length header field, the value of Content- |  | response has a Content-Length header field, the value of Content- |
| Length matches that of the stored response, the cache SHOULD update |  | Length matches that of the stored response, the cache SHOULD update |
| the stored response a described below; otherwise, the cache SHOULD |  | the stored response as described below; otherwise, the cache SHOULD |
| consider the stored response to be stale. |  | consider the stored response to be stale. |
| If a cache updates a stored response with the metadata provided in a |  | If a cache updates a stored response with the metadata provided in a |
| HEAD response, the cache MUST: |  | HEAD response, the cache MUST: |
| o delete any Warning header fields in the stored response with warn- |  | o delete any Warning header fields in the stored response with warn- |
| code 1xx (see Section 5.5); |  | code 1xx (see Section 5.5); |
| o retain any Warning header fields in the stored response with warn- |  | o retain any Warning header fields in the stored response with warn- |
| code 2xx; and, |  | code 2xx; and, |
| skipping to change at page 26, line 45 |  | skipping to change at page 26, line 45 |
| 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. |
| This directive uses the token form of the argument syntax; e.g., |  | This directive uses the token form of the argument syntax; e.g., |
| 's-maxage=10', not 's-maxage="10"'. A sender SHOULD NOT generate the |  | 's-maxage=10', not 's-maxage="10"'. A sender SHOULD NOT 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. A cache |
|  |  | MUST ignore unrecognized cache directives. |
| 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. |
| modifiers to the existing base of cache directives. |  |  |
| Both the new directive and the standard directive are supplied, such |  |  |
| that applications that do not understand the new directive will |  |  |
| default to the behavior specified by the standard directive, and |  |  |
| those that understand the new directive will recognize it as |  |  |
| modifying the requirements associated with the standard directive. |  |  |
| In this way, extensions to the cache-control directives can be made |  |  |
| without requiring changes to the base protocol. |  |  |
| This extension mechanism depends on an HTTP cache obeying all of the |  | Behavioral extensions are designed to work by acting as modifiers to |
| cache-control directives defined for its native HTTP-version, obeying |  | the existing base of cache directives. Both the new directive and |
| certain extensions, and ignoring all directives that it does not |  | the old directive are supplied, such that applications that do not |
| understand. |  | understand the new directive will default to the behavior specified |
|  |  | by the old directive, and those that understand the new directive |
|  |  | will recognize it as modifying the requirements associated with the |
|  |  | old directive. In this way, extensions to the existing cache-control |
|  |  | directives can be made without breaking deployed caches. |
| For example, consider a hypothetical new response directive called |  | For example, consider a hypothetical new response directive called |
| "community" that acts as a modifier to the private directive. We |  | "community" that acts as a modifier to the private directive: in |
| define this new directive to mean that, in addition to any private |  | addition to private caches, any cache that is shared only by members |
| cache, any cache that is shared only by members of the community |  | of the named community is allowed to cache the response. An origin |
| named within its value is allowed to cache the response. An origin |  |  |
| server wishing to allow the UCI community to use an otherwise private |  | server wishing to allow the UCI community to use an otherwise private |
| response in their shared cache(s) could do so by including |  | response in their shared cache(s) could do so by including |
| Cache-Control: private, community="UCI" |  | Cache-Control: private, community="UCI" |
| A cache seeing this header field will act correctly even if the cache |  | A cache that recognizes such a community cache-extension could |
| does not understand the community cache-extension, since it will also |  | broaden its behavior in accordance with that extension. A cache that |
| see and understand the private directive and thus default to the safe |  | does not recognize the community cache-extension would ignore it and |
| behavior. |  | adhere to the private directive. |
| A cache MUST ignore unrecognized cache directives; it is assumed that |  |  |
| any cache directive likely to be unrecognized by an HTTP/1.1 cache |  |  |
| will be combined with standard directives (or the response's default |  |  |
| cacheability) such that the cache behavior will remain minimally |  |  |
| correct even if the cache does not understand the extension(s). |  |  |
| 5.3. Expires |  | 5.3. Expires |
| The "Expires" header field gives the date/time after which the |  | The "Expires" header field gives the date/time after which the |
| response is considered stale. See Section 4.2 for further discussion |  | response is considered stale. See Section 4.2 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 30, line 40 |  | skipping to change at page 30, line 29 |
| If a sender generates one or more 1xx warn-codes in a message to be |  | If a sender generates one or more 1xx warn-codes in a message to be |
| sent to a recipient known to implement only HTTP/1.0, the sender MUST |  | sent to a recipient known to implement only HTTP/1.0, the sender MUST |
| include in each corresponding warning-value a warn-date that matches |  | include in each corresponding warning-value a warn-date that matches |
| the Date header field in the message. For example: |  | the Date header field in the message. For example: |
| HTTP/1.1 200 OK |  | HTTP/1.1 200 OK |
| Date: Sat, 25 Aug 2012 23:34:45 GMT |  | Date: Sat, 25 Aug 2012 23:34:45 GMT |
| Warning: 112 - "network down" "Sat, 25 Aug 2012 23:34:45 GMT" |  | Warning: 112 - "network down" "Sat, 25 Aug 2012 23:34:45 GMT" |
|  |  | Warnings have accompanying warn-text that describes the error, e.g., |
|  |  | for logging. It is advisory only, and its content does not affect |
|  |  | interpretation of the warn-code. |
| If a recipient that uses, evaluates, or displays Warning header |  | If a recipient that uses, evaluates, or displays Warning header |
| fields receives a warn-date that is different from the Date value in |  | fields receives a warn-date that is different from the Date value in |
| the same message, the recipient MUST exclude the warning-value |  | the same message, the recipient MUST exclude the warning-value |
| containing that warn-date before storing, forwarding, or using the |  | containing that warn-date before storing, forwarding, or using the |
| message. This allows recipients to exclude warning-values that were |  | message. This allows recipients to exclude warning-values that were |
| improperly retained after a cache validation. If all of the warning- |  | improperly retained after a cache validation. If all of the warning- |
| values are excluded, the recipient MUST exclude the Warning header |  | values are excluded, the recipient MUST exclude the Warning header |
| field as well. |  | field as well. |
| The following warn-codes are defined by this specification, each with |  | The following warn-codes are defined by this specification, each with |
| skipping to change at page 34, line 43 |  | skipping to change at page 34, line 43 |
| | Pragma | http | standard | Section 5.4 | |  | | Pragma | http | standard | Section 5.4 | |
| | Warning | http | standard | Section 5.5 | |  | | Warning | http | standard | Section 5.5 | |
| +-------------------+----------+----------+-------------+ |  | +-------------------+----------+----------+-------------+ |
| The change controller is: "IETF (iesg@ietf.org) - Internet |  | The change controller is: "IETF (iesg@ietf.org) - Internet |
| Engineering Task Force". |  | Engineering Task Force". |
| 8. Security Considerations |  | 8. Security Considerations |
| This section is meant to inform developers, information providers, |  | This section is meant to inform developers, information providers, |
| and users of known security concerns specific to HTTP/1.1 caching. |  | and users of known security concerns specific to HTTP caching. More |
| More general security considerations are addressed in HTTP messaging |  | general security considerations are addressed in HTTP messaging |
| [Part1] and semantics [Part2]. |  | [Part1] and semantics [Part2]. |
| Caches expose additional potential vulnerabilities, since the |  | Caches expose additional potential vulnerabilities, since the |
| contents of the cache represent an attractive target for malicious |  | contents of the cache represent an attractive target for malicious |
| exploitation. Because cache contents persist after an HTTP request |  | exploitation. Because cache contents persist after an HTTP request |
| is complete, an attack on the cache can reveal information long after |  | is complete, an attack on the cache can reveal information long after |
| a user believes that the information has been removed from the |  | a user believes that the information has been removed from the |
| network. Therefore, cache contents need to be protected as sensitive |  | network. Therefore, cache contents need to be protected as sensitive |
| information. |  | information. |
| Furthermore, the very use of a cache can bring about privacy |  | In particular, various attacks might be amplified by being stored in |
| concerns. For example, if two users share a cache, and the first one |  | a shared cache; such "cache poisoning" attacks use the cache to |
| browses to a site, the second may be able to detect that the other |  | distribute a malicious payload to many clients, and are especially |
| has been to that site, because the resources from it load more |  | effective when an attacker can use implementation flaws, elevated |
| quickly, thanks to the cache. |  | privileges, or other techniques to insert such a response into a |
|  |  | cache. One common attack vector for cache poisoning is to exploit |
| Implementation flaws might allow attackers to insert content into a |  | differences in message parsing on proxies and in user agents; see |
| cache ("cache poisoning"), leading to compromise of clients that |  | Section 3.3.3 of [Part1] for the relevant requirements. |
| trust that content. Because of their nature, these attacks are |  |  |
| difficult to mitigate. |  |  |
| Likewise, implementation flaws (as well as misunderstanding of cache |  | Likewise, implementation flaws (as well as misunderstanding of cache |
| operation) might lead to caching of sensitive information (e.g., |  | operation) might lead to caching of sensitive information (e.g., |
| authentication credentials) that is thought to be private, exposing |  | authentication credentials) that is thought to be private, exposing |
| it to unauthorized parties. |  | it to unauthorized parties. |
|  |  | Furthermore, the very use of a cache can bring about privacy |
|  |  | concerns. For example, if two users share a cache, and the first one |
|  |  | browses to a site, the second may be able to detect that the other |
|  |  | has been to that site, because the resources from it load more |
|  |  | quickly, thanks to the cache. |
| Note that the Set-Cookie response header field [RFC6265] does not |  | Note that the Set-Cookie response header field [RFC6265] does not |
| inhibit caching; a cacheable response with a Set-Cookie header field |  | inhibit caching; a cacheable response with a Set-Cookie header field |
| can be (and often is) used to satisfy subsequent requests to caches. |  | can be (and often is) used to satisfy subsequent requests to caches. |
| Servers who wish to control caching of these responses are encouraged |  | Servers who wish to control caching of these responses are encouraged |
| to emit appropriate Cache-Control response header fields. |  | to emit appropriate Cache-Control response header fields. |
| 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-25 (work in progress), |  | draft-ietf-httpbis-p1-messaging-26 (work in progress), |
| November 2013. |  | February 2014. |
| [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-25 (work in progress), |  | draft-ietf-httpbis-p2-semantics-26 (work in progress), |
| November 2013. |  | February 2014. |
| [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-25 (work in progress), |  | draft-ietf-httpbis-p4-conditional-26 (work in progress), |
| November 2013. |  | February 2014. |
| [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-25 (work in progress), |  | draft-ietf-httpbis-p5-range-26 (work in progress), |
| November 2013. |  | February 2014. |
| [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-25 (work in progress), |  | draft-ietf-httpbis-p7-auth-26 (work in progress), |
| November 2013. |  | February 2014. |
| [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 |
| skipping to change at page 37, line 30 |  | skipping to change at page 37, line 34 |
| Requirements regarding denial of service attack avoidance when |  | Requirements regarding denial of service attack avoidance when |
| performing invalidation have been clarified. (Section 4.4) |  | performing invalidation have been clarified. (Section 4.4) |
| Cache invalidation only occurs when a successful response is |  | Cache invalidation only occurs when a successful response is |
| received. (Section 4.4) |  | received. (Section 4.4) |
| Cache directives are explicitly defined to be case-insensitive. |  | Cache directives are explicitly defined to be case-insensitive. |
| Handling of multiple instances of cache directives when only one is |  | Handling of multiple instances of cache directives when only one is |
| expected is now defined. (Section 5.2) |  | expected is now defined. (Section 5.2) |
| The "no-store" cache request directive doesn't apply to responses; |  | The "no-store" request directive doesn't apply to responses; i.e., a |
| i.e., a cache can satisfy a request with no-store on it, and does not |  | cache can satisfy a request with no-store on it, and does not |
| invalidate it. (Section 5.2.1.5) |  | invalidate it. (Section 5.2.1.5) |
| The qualified forms of the private and no-cache cache directives are |  | The qualified forms of the private and no-cache cache directives are |
| noted to not be widely implemented; e.g., "private=foo" is |  | noted to not be widely implemented; e.g., "private=foo" is |
| interpreted by many caches as simply "private". Additionally, the |  | interpreted by many caches as simply "private". Additionally, the |
| meaning of the qualified form of no-cache has been clarified. |  | meaning of the qualified form of no-cache has been clarified. |
| (Section 5.2.2) |  | (Section 5.2.2) |
| The "no-cache" response cache directive's meaning has been clarified. |  | The "no-cache" response directive's meaning has been clarified. |
| (Section 5.2.2.2) |  | (Section 5.2.2.2) |
| The one-year limit on Expires header field values has been removed; |  | The one-year limit on Expires header field values has been removed; |
| instead, the reasoning for using a sensible value is given. |  | instead, the reasoning for using a sensible value is given. |
| (Section 5.3) |  | (Section 5.3) |
| The Pragma header field is now only defined for backwards |  | The Pragma header field is now only defined for backwards |
| compatibility; future pragmas are deprecated. (Section 5.4) |  | compatibility; future pragmas are deprecated. (Section 5.4) |
| Some requirements regarding production and processing of the Warning |  | Some requirements regarding production and processing of the Warning |
| skipping to change at page 40, line 18 |  | skipping to change at page 40, line 18 |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/499>: "RFC 1305 ref |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/499>: "RFC 1305 ref |
| needs to be updated to 5905" |  | needs to be updated to 5905" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/500>: "dangling |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/500>: "dangling |
| reference to cacheable status codes" |  | reference to cacheable status codes" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/512>: "APPSDIR |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/512>: "APPSDIR |
| review of draft-ietf-httpbis-p6-cache-24" |  | review of draft-ietf-httpbis-p6-cache-24" |
|  |  | D.2. Since draft-ietf-httpbis-p6-cache-25 |
|  |  | Closed issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/535>: "IESG ballot |
|  |  | on draft-ietf-httpbis-p6-cache-25" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/538>: "add |
|  |  | 'stateless' to Abstract" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/542>: "improve |
|  |  | introduction of list rule" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/549>: "augment |
|  |  | security considerations with pointers to current research" |
| Index |  | Index |
| 1 |  | 1 |
| 110 (warn-code) 31 |  | 110 (warn-code) 30 |
| 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 |
| skipping to change at page 41, line 48 |  | skipping to change at page 42, line 16 |
| 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) 26 |  | proxy-revalidate (cache directive) 26 |
| public (cache directive) 25 |  | public (cache directive) 25 |
| R |  | R |
| Response is Stale (warn-text) 31 |  | Response is Stale (warn-text) 30 |
| 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. 43 change blocks.
| 97 lines changed or deleted |  | 112 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/