| p6-cache.unpg.txt |  | rfc7234.txt |
--- | --- | --- | --- | ---
| HTTPbis Working Group R. Fielding, Ed. |  | Internet Engineering Task Force (IETF) R. Fielding, Ed. |
| Internet-Draft Adobe |  | Request for Comments: 7234 Adobe |
| Obsoletes: 2616 (if approved) M. Nottingham, Ed. |  | Obsoletes: 2616 M. Nottingham, Ed. |
| Intended status: Standards Track Akamai |  | Category: Standards Track Akamai |
| Expires: December 8, 2014 J. Reschke, Ed. |  | ISSN: 2070-1721 J. Reschke, Ed. |
| greenbytes |  | greenbytes |
| June 6, 2014 |  | June 2014 |
| Hypertext Transfer Protocol (HTTP/1.1): Caching |  | Hypertext Transfer Protocol (HTTP/1.1): Caching |
| draft-ietf-httpbis-p6-cache-latest |  |  |
| Abstract |  | Abstract |
| The Hypertext Transfer Protocol (HTTP) is a stateless application- |  | The Hypertext Transfer Protocol (HTTP) is a stateless application- |
| level protocol for distributed, collaborative, hypertext information |  | level protocol for distributed, collaborative, hypertext information |
| systems. This document defines HTTP caches and the associated header |  | systems. This document defines HTTP caches and the associated header |
| fields that control cache behavior or indicate cacheable response |  | fields that control cache behavior or indicate cacheable response |
| messages. |  | messages. |
| Editorial Note (To be removed by RFC Editor) |  |  |
| Discussion of this draft takes place on the HTTPBIS working group |  |  |
| mailing list (ietf-http-wg@w3.org), which is archived at |  |  |
| <http://lists.w3.org/Archives/Public/ietf-http-wg/>. |  |  |
| The current issues list is at |  |  |
| <http://tools.ietf.org/wg/httpbis/trac/report/3> and related |  |  |
| documents (including fancy diffs) can be found at |  |  |
| <http://tools.ietf.org/wg/httpbis/>. |  |  |
| _This is a temporary document for the purpose of tracking the |  |  |
| editorial changes made during the AUTH48 (RFC publication) phase._ |  |  |
| Status of This Memo |  | Status of This Memo |
| This Internet-Draft is submitted in full conformance with the |  | This is an Internet Standards Track document. |
| provisions of BCP 78 and BCP 79. |  |  |
| Internet-Drafts are working documents of the Internet Engineering |  | This document is a product of the Internet Engineering Task Force |
| Task Force (IETF). Note that other groups may also distribute |  | (IETF). It represents the consensus of the IETF community. It has |
| working documents as Internet-Drafts. The list of current Internet- |  | received public review and has been approved for publication by the |
| Drafts is at http://datatracker.ietf.org/drafts/current/. |  | Internet Engineering Steering Group (IESG). Further information on |
|  |  | Internet Standards is available in Section 2 of RFC 5741. |
| Internet-Drafts are draft documents valid for a maximum of six months |  | Information about the current status of this document, any errata, |
| and may be updated, replaced, or obsoleted by other documents at any |  | and how to provide feedback on it may be obtained at |
| time. It is inappropriate to use Internet-Drafts as reference |  | http://www.rfc-editor.org/info/rfc7234. |
| material or to cite them other than as "work in progress." |  |  |
| This Internet-Draft will expire on December 8, 2014. |  |  |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2014 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 |
| skipping to change at page 2, line 35 |  | skipping to change at page 2, line 34 |
| modifications of such material outside the IETF Standards Process. |  | modifications of such material outside the IETF Standards Process. |
| Without obtaining an adequate license from the person(s) controlling |  | Without obtaining an adequate license from the person(s) controlling |
| the copyright in such materials, this document may not be modified |  | the copyright in such materials, this document may not be modified |
| outside the IETF Standards Process, and derivative works of it may |  | outside the IETF Standards Process, and derivative works of it may |
| not be created outside the IETF Standards Process, except to format |  | not be created outside the IETF Standards Process, except to format |
| it for publication as an RFC or to translate it into languages other |  | it for publication as an RFC or to translate it into languages other |
| than English. |  | than English. |
| Table of Contents |  | Table of Contents |
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . 8 |  | 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 .................................................11 |
| 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 ....................13 |
| 4.2.3. Calculating Age . . . . . . . . . . . . . . . . . . . 13 |  | 4.2.3. Calculating Age ....................................13 |
| 4.2.4. Serving Stale Responses . . . . . . . . . . . . . . . 15 |  | 4.2.4. Serving Stale Responses ............................15 |
| 4.3. Validation . . . . . . . . . . . . . . . . . . . . . . . . 15 |  | 4.3. Validation ................................................16 |
| 4.3.1. Sending a Validation Request . . . . . . . . . . . . . 15 |  | 4.3.1. Sending a Validation Request .......................16 |
| 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 .....................18 |
| 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 . . . . . . . . . . . . 19 |  | 4.3.5. Freshening Responses via HEAD ......................19 |
| 4.4. Invalidation . . . . . . . . . . . . . . . . . . . . . . . 19 |  | 4.4. Invalidation ..............................................20 |
| 5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 20 |  | 5. Header Field Definitions .......................................21 |
| 5.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 |  | 5.1. Age .......................................................21 |
| 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 ...................22 |
| 5.2.2. Response Cache-Control Directives . . . . . . . . . . 23 |  | 5.2.2. Response Cache-Control Directives ..................24 |
| 5.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 26 |  | 5.2.3. Cache Control Extensions ...........................27 |
| 5.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 27 |  | 5.3. Expires ...................................................28 |
| 5.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 28 |  | 5.4. Pragma ....................................................29 |
| 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" .............32 |
| 5.5.6. Warning: 214 - "Transformation Applied" . . . . . . . 31 |  | 5.5.6. Warning: 214 - "Transformation Applied" ............32 |
| 5.5.7. Warning: 299 - "Miscellaneous Persistent Warning" . . 31 |  | 5.5.7. Warning: 299 - "Miscellaneous Persistent Warning" ..32 |
| 6. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 31 |  | 6. History Lists ..................................................32 |
| 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 ....33 |
| 7.1.3. Registrations . . . . . . . . . . . . . . . . . . . . 32 |  | 7.1.3. Registrations ......................................33 |
| 7.2. Warn Code Registry . . . . . . . . . . . . . . . . . . . . 33 |  | 7.2. Warn Code Registry ........................................34 |
| 7.2.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 33 |  | 7.2.1. Procedure ..........................................34 |
| 7.2.2. Registrations . . . . . . . . . . . . . . . . . . . . 33 |  | 7.2.2. Registrations ......................................34 |
| 7.3. Header Field Registration . . . . . . . . . . . . . . . . 34 |  | 7.3. Header Field Registration .................................34 |
| 8. Security Considerations . . . . . . . . . . . . . . . . . . . 34 |  | 8. Security Considerations ........................................35 |
| 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 |  | 9. Acknowledgments ................................................36 |
| 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 |  | 10. References ....................................................36 |
| 10.1. Normative References . . . . . . . . . . . . . . . . . . . 35 |  | 10.1. Normative References .....................................36 |
| 10.2. Informative References . . . . . . . . . . . . . . . . . . 36 |  | 10.2. Informative References ...................................37 |
| Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 36 |  | Appendix A. Changes from RFC 2616 .................................38 |
| Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 38 |  | Appendix B. Imported ABNF .........................................39 |
| Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 38 |  | Appendix C. Collected ABNF ........................................39 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 |  | 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 14 |  | skipping to change at page 5, line 16 |
| operators expanded to standard ABNF notation. |  | 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 |
| negative integer range. If a cache receives a delta-seconds value |  | non-negative integer range. If a cache receives a delta-seconds |
| greater than the greatest integer it can represent, or if any of its |  | value greater than the greatest integer it can represent, or if any |
| subsequent calculations overflows, the cache MUST consider the value |  | of its subsequent calculations overflows, the cache MUST consider the |
| to be either 2147483648 (2^31) or the greatest positive integer it |  | value to be either 2147483648 (2^31) or the greatest positive integer |
| can conveniently represent. |  | it can conveniently represent. |
| Note: The value 2147483648 is here for historical reasons, |  | Note: The value 2147483648 is here for historical reasons, |
| effectively represents infinity (over 68 years), and does not need |  | effectively represents infinity (over 68 years), and does not need |
| to be stored in binary form; an implementation could produce it as |  | to be stored in binary form; an implementation could produce it as |
| a canned string if any overflow occurs, even if the calculations |  | a canned string if any overflow occurs, even if the calculations |
| 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. |
| skipping to change at page 8, line 23 |  | skipping to change at page 8, line 26 |
| Range specifiers ([RFC7233]). After several such transfers, a cache |  | Range specifiers ([RFC7233]). After several such transfers, a cache |
| might have received several ranges of the same representation. A |  | might have received several ranges of the same representation. A |
| cache MAY combine these ranges into a single stored response, and |  | cache MAY combine these ranges into a single stored response, and |
| reuse that response to satisfy later requests, if they all share the |  | reuse that response to satisfy later requests, if they all share the |
| same strong validator and the cache complies with the client |  | same strong validator and the cache complies with the client |
| requirements in Section 4.3 of [RFC7233]. |  | requirements in Section 4.3 of [RFC7233]. |
| When combining the new response with one or more stored responses, a |  | When combining the new response with one or more stored responses, a |
| cache MUST: |  | 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 |
| code 1xx (see Section 5.5); |  | warn-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 |
| code 2xx; and, |  | warn-code 2xx; and, |
| o use other header fields provided in the new response, aside from |  | o use other header fields provided in the new response, aside from |
| Content-Range, to replace all instances of the corresponding |  | Content-Range, to replace all instances of the corresponding |
| header fields in the stored response. |  | header fields in the stored response. |
| 4. Constructing Responses from Caches |  | 4. Constructing Responses from Caches |
| When presented with a request, a cache MUST NOT reuse a stored |  | When presented with a request, a cache MUST NOT reuse a stored |
| response, unless: |  | response, unless: |
| skipping to change at page 11, line 41 |  | skipping to change at page 12, line 8 |
| freshness_lifetime is defined in Section 4.2.1; current_age is |  | freshness_lifetime is defined in Section 4.2.1; current_age is |
| defined in Section 4.2.3. |  | defined in Section 4.2.3. |
| Clients can send the max-age or min-fresh cache directives in a |  | Clients can send the max-age or min-fresh cache directives in a |
| request to constrain or relax freshness calculations for the |  | request to constrain or relax freshness calculations for the |
| corresponding response (Section 5.2.1). |  | corresponding response (Section 5.2.1). |
| When calculating freshness, to avoid common problems in date parsing: |  | When calculating freshness, to avoid common problems in date parsing: |
| o Although all date formats are specified to be case-sensitive, a |  | o Although all date formats are specified to be case-sensitive, a |
| cache recipient SHOULD match day, week, and time-zone names case- |  | cache recipient SHOULD match day, week, and time-zone names |
| insensitively. |  | case-insensitively. |
| o If a cache recipient's internal implementation of time has less |  | o If a cache recipient's internal implementation of time has less |
| resolution than the value of an HTTP-date, the recipient MUST |  | resolution than the value of an HTTP-date, the recipient MUST |
| internally represent a parsed Expires date as the nearest time |  | internally represent a parsed Expires date as the nearest time |
| equal to or earlier than the received value. |  | equal to or earlier than the received value. |
| o A cache recipient MUST NOT allow local time zones to influence the |  | o A cache recipient MUST NOT allow local time zones to influence the |
| calculation or comparison of an age or expiration time. |  | calculation or comparison of an age or expiration time. |
| o A cache recipient SHOULD consider a date with a zone abbreviation |  | o A cache recipient SHOULD consider a date with a zone abbreviation |
| skipping to change at page 15, line 22 |  | skipping to change at page 15, line 40 |
| according to the calculations in Section 4.2. |  | according to the calculations in Section 4.2. |
| A cache MUST NOT generate a stale response if it is prohibited by an |  | A cache MUST NOT generate a stale response if it is prohibited by an |
| explicit in-protocol directive (e.g., by a "no-store" or "no-cache" |  | explicit in-protocol directive (e.g., by a "no-store" or "no-cache" |
| cache directive, a "must-revalidate" cache-response-directive, or an |  | cache directive, a "must-revalidate" cache-response-directive, or an |
| applicable "s-maxage" or "proxy-revalidate" cache-response-directive; |  | applicable "s-maxage" or "proxy-revalidate" cache-response-directive; |
| see Section 5.2.2). |  | see Section 5.2.2). |
| A cache MUST NOT send stale responses unless it is disconnected |  | A cache MUST NOT send stale responses unless it is disconnected |
| (i.e., it cannot contact the origin server or otherwise find a |  | (i.e., it cannot contact the origin server or otherwise find a |
| forward path) or doing so is explicitly allowed (e.g., by the max- |  | forward path) or doing so is explicitly allowed (e.g., by the |
| stale request directive; see Section 5.2.1). |  | max-stale request directive; see Section 5.2.1). |
| A cache SHOULD generate a Warning header field with the 110 warn-code |  | A cache SHOULD generate a Warning header field with the 110 warn-code |
| (see Section 5.5.1) in stale responses. Likewise, a cache SHOULD |  | (see Section 5.5.1) in stale responses. Likewise, a cache SHOULD |
| generate a 112 warn-code (see Section 5.5.3) in stale responses if |  | generate a 112 warn-code (see Section 5.5.3) in stale responses if |
| the cache is disconnected. |  | the cache is disconnected. |
| A cache SHOULD NOT generate a new Warning header field when |  | A cache SHOULD NOT generate a new Warning header field when |
| forwarding a response that does not have an Age header field, even if |  | forwarding a response that does not have an Age header field, even if |
| the response is already stale. A cache need not validate a response |  | the response is already stale. A cache need not validate a response |
| that merely became stale in transit. |  | that merely became stale in transit. |
| skipping to change at page 16, line 6 |  | skipping to change at page 16, line 25 |
| 4.3.1. Sending a Validation Request |  | 4.3.1. Sending a Validation Request |
| When sending a conditional request for cache validation, a cache |  | When sending a conditional request for cache validation, a cache |
| sends one or more precondition header fields containing validator |  | sends one or more precondition header fields containing validator |
| metadata from its stored response(s), which is then compared by |  | metadata from its stored response(s), which is then compared by |
| recipients to determine whether a stored response is equivalent to a |  | recipients to determine whether a stored response is equivalent to a |
| current representation of the resource. |  | current representation of the resource. |
| One such validator is the timestamp given in a Last-Modified header |  | One such validator is the timestamp given in a Last-Modified header |
| field (Section 2.2 of [RFC7232]), which can be used in an If- |  | field (Section 2.2 of [RFC7232]), which can be used in an |
| Modified-Since header field for response validation, or in an If- |  | If-Modified-Since header field for response validation, or in an |
| Unmodified-Since or If-Range header field for representation |  | If-Unmodified-Since or If-Range header field for representation |
| selection (i.e., the client is referring specifically to a previously |  | selection (i.e., the client is referring specifically to a previously |
| obtained representation with that timestamp). |  | obtained representation with that timestamp). |
| Another validator is the entity-tag given in an ETag header field |  | Another validator is the entity-tag given in an ETag header field |
| (Section 2.3 of [RFC7232]). One or more entity-tags, indicating one |  | (Section 2.3 of [RFC7232]). One or more entity-tags, indicating one |
| or more stored responses, can be used in an If-None-Match header |  | or more stored responses, can be used in an If-None-Match header |
| field for response validation, or in an If-Match or If-Range header |  | field for response validation, or in an If-Match or If-Range header |
| field for representation selection (i.e., the client is referring |  | field for representation selection (i.e., the client is referring |
| specifically to one or more previously obtained representations with |  | specifically to one or more previously obtained representations with |
| the listed entity-tags). |  | the listed entity-tags). |
| skipping to change at page 16, line 42 |  | skipping to change at page 17, line 12 |
| received in that request with respect to the corresponding validators |  | received in that request with respect to the corresponding validators |
| contained within the selected response. A cache MUST NOT evaluate |  | contained within the selected response. A cache MUST NOT evaluate |
| conditional header fields that are only applicable to an origin |  | conditional header fields that are only applicable to an origin |
| server, found in a request with semantics that cannot be satisfied |  | server, found in a request with semantics that cannot be satisfied |
| with a cached response, or applied to a target resource for which it |  | with a cached response, or applied to a target resource for which it |
| has no stored responses; such preconditions are likely intended for |  | has no stored responses; such preconditions are likely intended for |
| some other (inbound) server. |  | some other (inbound) server. |
| The proper evaluation of conditional requests by a cache depends on |  | The proper evaluation of conditional requests by a cache depends on |
| the received precondition header fields and their precedence, as |  | the received precondition header fields and their precedence, as |
| defined in Section 6 of [RFC7232]. The If-Match and If-Unmodified- |  | defined in Section 6 of [RFC7232]. The If-Match and |
| Since conditional header fields are not applicable to a cache. |  | If-Unmodified-Since conditional header fields are not applicable to a |
|  |  | cache. |
| A request containing an If-None-Match header field (Section 3.2 of |  | A request containing an If-None-Match header field (Section 3.2 of |
| [RFC7232]) indicates that the client wants to validate one or more of |  | [RFC7232]) indicates that the client wants to validate one or more of |
| its own stored responses in comparison to whichever stored response |  | its own stored responses in comparison to whichever stored response |
| is selected by the cache. If the field-value is "*", or if the |  | is selected by the cache. If the field-value is "*", or if the |
| field-value is a list of entity-tags and at least one of them matches |  | field-value is a list of entity-tags and at least one of them matches |
| the entity-tag of the selected stored response, a cache recipient |  | the entity-tag of the selected stored response, a cache recipient |
| SHOULD generate a 304 (Not Modified) response (using the metadata of |  | SHOULD generate a 304 (Not Modified) response (using the metadata of |
| the selected stored response) instead of sending that stored |  | the selected stored response) instead of sending that stored |
| response. |  | response. |
| skipping to change at page 17, line 28 |  | skipping to change at page 17, line 48 |
| corresponding stored response, as updated by the 304 response |  | corresponding stored response, as updated by the 304 response |
| metadata (Section 4.3.4). |  | metadata (Section 4.3.4). |
| If an If-None-Match header field is not present, a request containing |  | If an If-None-Match header field is not present, a request containing |
| an If-Modified-Since header field (Section 3.3 of [RFC7232]) |  | an If-Modified-Since header field (Section 3.3 of [RFC7232]) |
| indicates that the client wants to validate one or more of its own |  | indicates that the client wants to validate one or more of its own |
| stored responses by modification date. A cache recipient SHOULD |  | stored responses by modification date. A cache recipient SHOULD |
| generate a 304 (Not Modified) response (using the metadata of the |  | generate a 304 (Not Modified) response (using the metadata of the |
| selected stored response) if one of the following cases is true: 1) |  | selected stored response) if one of the following cases is true: 1) |
| the selected stored response has a Last-Modified field-value that is |  | the selected stored response has a Last-Modified field-value that is |
| earlier than or equal to the conditional timestamp; 2) no Last- |  | earlier than or equal to the conditional timestamp; 2) no |
| Modified field is present in the selected stored response, but it has |  | Last-Modified field is present in the selected stored response, but |
| a Date field-value that is earlier than or equal to the conditional |  | it has a Date field-value that is earlier than or equal to the |
| timestamp; or, 3) neither Last-Modified nor Date is present in the |  | conditional timestamp; or, 3) neither Last-Modified nor Date is |
| selected stored response, but the cache recorded it as having been |  | present in the selected stored response, but the cache recorded it as |
| received at a time earlier than or equal to the conditional |  | having been received at a time earlier than or equal to the |
| timestamp. |  | conditional timestamp. |
| A cache that implements partial responses to range requests, as |  | A cache that implements partial responses to range requests, as |
| defined in [RFC7233], also needs to evaluate a received If-Range |  | defined in [RFC7233], also needs to evaluate a received If-Range |
| header field (Section 3.2 of [RFC7233]) with respect to its selected |  | header field (Section 3.2 of [RFC7233]) with respect to its selected |
| stored response. |  | stored response. |
| 4.3.3. Handling a Validation Response |  | 4.3.3. Handling a Validation Response |
| Cache handling of a response to a conditional request is dependent |  | Cache handling of a response to a conditional request is dependent |
| upon its status code: |  | upon its status code: |
| skipping to change at page 18, line 43 |  | skipping to change at page 19, line 18 |
| o If the new response does not include any form of validator (such |  | o If the new response does not include any form of validator (such |
| as in the case where a client generates an If-Modified-Since |  | as in the case where a client generates an If-Modified-Since |
| request from a source other than the Last-Modified response header |  | request from a source other than the Last-Modified response header |
| field), and there is only one stored response, and that stored |  | field), and there is only one stored response, and that stored |
| response also lacks a validator, then that stored response is |  | response also lacks a validator, then that stored response is |
| selected for update. |  | selected for update. |
| If a stored response is selected for update, the cache MUST: |  | If a stored response is selected for update, 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 |
| code 1xx (see Section 5.5); |  | warn-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 |
| code 2xx; and, |  | warn-code 2xx; and, |
| o use other header fields provided in the 304 (Not Modified) |  | o use other header fields provided in the 304 (Not Modified) |
| response to replace all instances of the corresponding header |  | response to replace all instances of the corresponding header |
| fields in the stored response. |  | fields in the stored response. |
| 4.3.5. Freshening Responses via HEAD |  | 4.3.5. Freshening Responses via HEAD |
| A response to the HEAD method is identical to what an equivalent |  | A response to the HEAD method is identical to what an equivalent |
| request made with a GET would have been, except it lacks a body. |  | request made with a GET would have been, except it lacks a body. |
| This property of HEAD responses can be used to invalidate or update a |  | This property of HEAD responses can be used to invalidate or update a |
| skipping to change at page 19, line 23 |  | skipping to change at page 19, line 46 |
| desired even if it has changed. |  | desired even if it has changed. |
| 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 |
| Length matches that of the stored response, the cache SHOULD update |  | Content-Length matches that of the stored response, the cache SHOULD |
| the stored response as described below; otherwise, the cache SHOULD |  | update the stored response as described below; otherwise, the cache |
| consider the stored response to be stale. |  | SHOULD 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 |
| code 1xx (see Section 5.5); |  | warn-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 |
| code 2xx; and, |  | warn-code 2xx; and, |
| o use other header fields provided in the HEAD response to replace |  | o use other header fields provided in the HEAD response to replace |
| all instances of the corresponding header fields in the stored |  | all instances of the corresponding header fields in the stored |
| response and append new header fields to the stored response's |  | response and append new header fields to the stored response's |
| header section unless otherwise restricted by the Cache-Control |  | header section unless otherwise restricted by the Cache-Control |
| header field. |  | header field. |
| 4.4. Invalidation |  | 4.4. Invalidation |
| Because unsafe request methods (Section 4.2.1 of [RFC7231]) such as |  | Because unsafe request methods (Section 4.2.1 of [RFC7231]) such as |
| skipping to change at page 21, line 24 |  | skipping to change at page 21, line 47 |
| Cache-Control directives defined elsewhere are handled. |  | Cache-Control directives defined elsewhere are handled. |
| Note: Some HTTP/1.0 caches might not implement Cache-Control. |  | Note: Some HTTP/1.0 caches might not implement Cache-Control. |
| A proxy, whether or not it implements a cache, MUST pass cache |  | A proxy, whether or not it implements a cache, MUST pass cache |
| directives through in forwarded messages, regardless of their |  | directives through in forwarded messages, regardless of their |
| significance to that application, since the directives might be |  | significance to that application, since the directives might be |
| applicable to all recipients along the request/response chain. It is |  | applicable to all recipients along the request/response chain. It is |
| not possible to target a directive to a specific cache. |  | not possible to target a directive to a specific cache. |
| Cache directives are identified by a token, to be compared case- |  | Cache directives are identified by a token, to be compared |
| insensitively, and have an optional argument, that can use both token |  | case-insensitively, and have an optional argument, that can use both |
| and quoted-string syntax. For the directives defined below that |  | token and quoted-string syntax. For the directives defined below |
| define arguments, recipients ought to accept both forms, even if one |  | that define arguments, recipients ought to accept both forms, even if |
| is documented to be preferred. For any directive not defined by this |  | one is documented to be preferred. For any directive not defined by |
| specification, a recipient MUST accept both forms. |  | this specification, a recipient MUST accept both forms. |
| Cache-Control = 1#cache-directive |  | Cache-Control = 1#cache-directive |
| cache-directive = token [ "=" ( token / quoted-string ) ] |  | cache-directive = token [ "=" ( token / quoted-string ) ] |
| For the cache directives defined below, no argument is defined (nor |  | For the cache directives defined below, no argument is defined (nor |
| allowed) unless stated otherwise. |  | allowed) unless stated otherwise. |
| 5.2.1. Request Cache-Control Directives |  | 5.2.1. Request Cache-Control Directives |
| skipping to change at page 23, line 5 |  | skipping to change at page 23, line 27 |
| 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 |
| store any part of either this request or any response to it. This |  | store any part of either this request or any response to it. 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 |
| effort attempt to remove the information from volatile storage as |  | best-effort attempt to remove the information from volatile storage |
| promptly as possible after forwarding it. |  | as promptly as possible after forwarding it. |
| This directive is NOT a reliable or sufficient mechanism for ensuring |  | This directive is NOT a reliable or sufficient mechanism for ensuring |
| privacy. In particular, malicious or compromised caches might not |  | privacy. In particular, malicious or compromised caches might not |
| recognize or obey this directive, and communications networks might |  | recognize or obey this directive, and communications networks might |
| be vulnerable to eavesdropping. |  | be vulnerable to eavesdropping. |
| Note that if a request containing this directive is satisfied from a |  | Note that if a request containing this directive is satisfied from a |
| cache, the no-store request directive does not apply to the already |  | cache, the no-store request directive does not apply to the already |
| stored response. |  | stored response. |
| skipping to change at page 24, line 34 |  | skipping to change at page 25, line 10 |
| 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 |  | This directive uses the quoted-string form of the argument syntax. A |
| sender SHOULD NOT generate the token form (even if quoting appears |  | sender SHOULD NOT generate the token form (even if quoting appears |
| not to be needed for single-entry lists). |  | 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, |
| cache response directives with field-names are often handled by |  | no-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. |
| 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 |
| effort attempt to remove the information from volatile storage as |  | best-effort attempt to remove the information from volatile storage |
| promptly as possible after forwarding it. |  | as promptly as possible after forwarding it. |
| This directive is NOT a reliable or sufficient mechanism for ensuring |  | This directive is NOT a reliable or sufficient mechanism for ensuring |
| privacy. In particular, malicious or compromised caches might not |  | privacy. In particular, malicious or compromised caches might not |
| recognize or obey this directive, and communications networks might |  | recognize or obey this directive, and communications networks might |
| be vulnerable to eavesdropping. |  | be vulnerable to eavesdropping. |
| 5.2.2.4. no-transform |  | 5.2.2.4. no-transform |
| The "no-transform" response directive indicates that an intermediary |  | The "no-transform" response directive indicates that an intermediary |
| (regardless of whether it implements a cache) MUST NOT transform the |  | (regardless of whether it implements a cache) MUST NOT transform the |
| skipping to change at page 30, line 38 |  | skipping to change at page 31, line 23 |
| Warnings have accompanying warn-text that describes the error, e.g., |  | Warnings have accompanying warn-text that describes the error, e.g., |
| for logging. It is advisory only, and its content does not affect |  | for logging. It is advisory only, and its content does not affect |
| interpretation of the warn-code. |  | 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 |
| values are excluded, the recipient MUST exclude the Warning header |  | warning-values are excluded, the recipient MUST exclude the Warning |
| field as well. |  | header 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 |
| a recommended warn-text in English, and a description of its meaning. |  | a recommended warn-text in English, and a description of its meaning. |
| The procedure for defining additional warn codes is described in |  | The procedure for defining additional warn codes is described in |
| Section 7.2.1. |  | Section 7.2.1. |
| 5.5.1. Warning: 110 - "Response is Stale" |  | 5.5.1. Warning: 110 - "Response is Stale" |
| A cache SHOULD generate this whenever the sent response is stale. |  | A cache SHOULD generate this whenever the sent response is stale. |
| skipping to change at page 31, line 32 |  | skipping to change at page 32, line 15 |
| 5.5.5. Warning: 199 - "Miscellaneous Warning" |  | 5.5.5. Warning: 199 - "Miscellaneous Warning" |
| The warning text can include arbitrary information to be presented to |  | The warning text can include arbitrary information to be presented to |
| a human user or logged. A system receiving this warning MUST NOT |  | a human user or logged. A system receiving this warning MUST NOT |
| take any automated action, besides presenting the warning to the |  | take any automated action, besides presenting the warning to the |
| user. |  | user. |
| 5.5.6. Warning: 214 - "Transformation Applied" |  | 5.5.6. Warning: 214 - "Transformation Applied" |
| This Warning code MUST be added by a proxy if it applies any |  | This Warning code MUST be added by a proxy if it applies any |
| transformation to the representation, such as changing the content- |  | transformation to the representation, such as changing the |
| coding, media-type, or modifying the representation data, unless this |  | content-coding, media-type, or modifying the representation data, |
| Warning code already appears in the response. |  | unless this Warning code already appears in the response. |
| 5.5.7. Warning: 299 - "Miscellaneous Persistent Warning" |  | 5.5.7. Warning: 299 - "Miscellaneous Persistent Warning" |
| The warning text can include arbitrary information to be presented to |  | The warning text can include arbitrary information to be presented to |
| a human user or logged. A system receiving this warning MUST NOT |  | a human user or logged. A system receiving this warning MUST NOT |
| take any automated action. |  | take any automated action. |
| 6. History Lists |  | 6. History Lists |
| User agents often have history mechanisms, such as "Back" buttons and |  | User agents often have history mechanisms, such as "Back" buttons and |
| skipping to change at page 35, line 51 |  | skipping to change at page 36, line 36 |
| 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. |
| [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |  | [RFC7230] 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", |
| RFC 7230, June 2014. |  | RFC 7230, June 2014. |
| [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |  | [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |
| Protocol (HTTP/1.1): Semantics and Content", |  | Protocol (HTTP/1.1): Semantics and Content", RFC 7231, |
| draft-ietf-httpbis-p2-semantics-latest (work in progress), |  |  |
| June 2014. |  | June 2014. |
| [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |  | [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |
| Protocol (HTTP/1.1): Conditional Requests", |  | Protocol (HTTP/1.1): Conditional Requests", RFC 7232, |
| draft-ietf-httpbis-p4-conditional-latest (work in |  | June 2014. |
| progress), June 2014. |  |  |
| [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |  | [RFC7233] 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-latest (work in progress), |  | RFC 7233, June 2014. |
| June 2014. |  |  |
| [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |  | [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |
| Protocol (HTTP/1.1): Authentication", |  | Protocol (HTTP/1.1): Authentication", RFC 7235, June 2014. |
| draft-ietf-httpbis-p7-auth-latest (work in progress), |  |  |
| June 2014. |  |  |
| 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. |
| [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. |
| skipping to change at page 39, line 50 |  | skipping to change at page 41, line 8 |
| 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 |
| ] |  | ] |
| 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) 32 |
| 2 |  | 2 |
| 214 (warn-code) 31 |  | 214 (warn-code) 32 |
| 299 (warn-code) 31 |  | 299 (warn-code) 32 |
| A |  | A |
| age 10 |  | age 11 |
| Age header field 20 |  | Age header field 21 |
| C |  | C |
| cache 4 |  | cache 4 |
| cache entry 5 |  | cache entry 5 |
| cache key 5-6 |  | cache key 5-6 |
| Cache-Control header field 21 |  | 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 28 |
| explicit expiration time 10 |  | explicit expiration time 11 |
| F |  | F |
| fresh 10 |  | fresh 11 |
| freshness lifetime 10 |  | freshness lifetime 11 |
| G |  | G |
| Grammar |  | Grammar |
| Age 20 |  | Age 21 |
| Cache-Control 21 |  | Cache-Control 22 |
| cache-directive 21 |  | cache-directive 22 |
| delta-seconds 5 |  | delta-seconds 5 |
| Expires 27 |  | Expires 28 |
| extension-pragma 28 |  | extension-pragma 29 |
| Pragma 28 |  | Pragma 29 |
| pragma-directive 28 |  | pragma-directive 29 |
| warn-agent 29 |  | warn-agent 29 |
| warn-code 29 |  | warn-code 29 |
| warn-date 29 |  | warn-date 29 |
| 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 11 |
| M |  | M |
| max-age (cache directive) 21, 26 |  | max-age (cache directive) 22, 26 |
| max-stale (cache directive) 22 |  | 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) 32 |
| Miscellaneous Warning (warn-text) 31 |  | Miscellaneous Warning (warn-text) 32 |
| must-revalidate (cache directive) 23 |  | must-revalidate (cache directive) 24 |
| N |  | N |
| no-cache (cache directive) 22, 24 |  | no-cache (cache directive) 23, 25 |
| no-store (cache directive) 22, 24 |  | no-store (cache directive) 23, 24 |
| no-transform (cache directive) 23, 25 |  | 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 29 |
| 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) 30 |  | 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) 27 |
| shared cache 4 |  | shared cache 4 |
| stale 10 |  | stale 11 |
| strong validator 18 |  | strong validator 18 |
| T |  | T |
| Transformation Applied (warn-text) 31 |  | Transformation Applied (warn-text) 32 |
| V |  | V |
| validator 15 |  | validator 16 |
| W |  | W |
| Warning header field 29 |  | Warning header field 29 |
| Authors' Addresses |  | Authors' Addresses |
| Roy T. Fielding (editor) |  | Roy T. Fielding (editor) |
| Adobe Systems Incorporated |  | Adobe Systems Incorporated |
| 345 Park Ave |  | 345 Park Ave |
| San Jose, CA 95110 |  | San Jose, CA 95110 |
End of changes. 48 change blocks.
| 188 lines changed or deleted |  | 166 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/