draft-ietf-httpbis-cache-14.txt | draft-ietf-httpbis-cache-latest.txt | |||
---|---|---|---|---|
HTTP Working Group R. Fielding, Ed. | HTTP Working Group R. Fielding, Ed. | |||
Internet-Draft Adobe | Internet-Draft Adobe | |||
Obsoletes: 7234 (if approved) M. Nottingham, Ed. | Obsoletes: 7234 (if approved) M. Nottingham, Ed. | |||
Intended status: Standards Track Fastly | Intended status: Standards Track Fastly | |||
Expires: July 17, 2021 J. Reschke, Ed. | Expires: August 30, 2021 J. Reschke, Ed. | |||
greenbytes | greenbytes | |||
January 13, 2021 | February 26, 2021 | |||
HTTP Caching | HTTP Caching | |||
draft-ietf-httpbis-cache-14 | draft-ietf-httpbis-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. | |||
This document obsoletes RFC 7234. | This document obsoletes RFC 7234. | |||
skipping to change at page 1, line 36 ¶ | skipping to change at page 1, line 36 ¶ | |||
This note is to be removed before publishing as an RFC. | This note is to be removed before publishing as an RFC. | |||
Discussion of this draft takes place on the HTTP working group | Discussion of this draft takes place on the HTTP working group | |||
mailing list (ietf-http-wg@w3.org), which is archived at | mailing list (ietf-http-wg@w3.org), which is archived at | |||
<https://lists.w3.org/Archives/Public/ietf-http-wg/>. | <https://lists.w3.org/Archives/Public/ietf-http-wg/>. | |||
Working Group information can be found at <https://httpwg.org/>; | Working Group information can be found at <https://httpwg.org/>; | |||
source code and issues list for this draft can be found at | source code and issues list for this draft can be found at | |||
<https://github.com/httpwg/http-core>. | <https://github.com/httpwg/http-core>. | |||
The changes in this draft are summarized in Appendix C.15. | The changes in this draft are summarized in Appendix C.16. | |||
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 https://datatracker.ietf.org/drafts/current/. | Drafts is at https://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 July 17, 2021. | This Internet-Draft will expire on August 30, 2021. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2021 IETF Trust and the persons identified as the | Copyright (c) 2021 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 (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
skipping to change at page 2, line 49 ¶ | skipping to change at page 2, line 49 ¶ | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5 | 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5 | |||
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5 | 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5 | |||
1.3. Delta Seconds . . . . . . . . . . . . . . . . . . . . . . 5 | 1.3. Delta Seconds . . . . . . . . . . . . . . . . . . . . . . 5 | |||
2. Overview of Cache Operation . . . . . . . . . . . . . . . . . 6 | 2. Overview of Cache Operation . . . . . . . . . . . . . . . . . 6 | |||
3. Storing Responses in Caches . . . . . . . . . . . . . . . . . 7 | 3. Storing Responses in Caches . . . . . . . . . . . . . . . . . 7 | |||
3.1. Storing Header and Trailer Fields . . . . . . . . . . . . 8 | 3.1. Storing Header and Trailer Fields . . . . . . . . . . . . 8 | |||
3.2. Updating Stored Header Fields . . . . . . . . . . . . . . 9 | 3.2. Updating Stored Header Fields . . . . . . . . . . . . . . 9 | |||
3.3. Storing Incomplete Responses . . . . . . . . . . . . . . 10 | 3.3. Storing Incomplete Responses . . . . . . . . . . . . . . 10 | |||
3.4. Combining Partial Content . . . . . . . . . . . . . . . . 10 | 3.4. Combining Partial Content . . . . . . . . . . . . . . . . 11 | |||
3.5. Storing Responses to Authenticated Requests . . . . . . . 10 | 3.5. Storing Responses to Authenticated Requests . . . . . . . 11 | |||
4. Constructing Responses from Caches . . . . . . . . . . . . . 11 | 4. Constructing Responses from Caches . . . . . . . . . . . . . 11 | |||
4.1. Calculating Cache Keys with Vary . . . . . . . . . . . . 12 | 4.1. Calculating Cache Keys with Vary . . . . . . . . . . . . 12 | |||
4.2. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 13 | 4.2. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
4.2.1. Calculating Freshness Lifetime . . . . . . . . . . . 15 | 4.2.1. Calculating Freshness Lifetime . . . . . . . . . . . 15 | |||
4.2.2. Calculating Heuristic Freshness . . . . . . . . . . . 15 | 4.2.2. Calculating Heuristic Freshness . . . . . . . . . . . 16 | |||
4.2.3. Calculating Age . . . . . . . . . . . . . . . . . . . 16 | 4.2.3. Calculating Age . . . . . . . . . . . . . . . . . . . 17 | |||
4.2.4. Serving Stale Responses . . . . . . . . . . . . . . . 17 | 4.2.4. Serving Stale Responses . . . . . . . . . . . . . . . 18 | |||
4.3. Validation . . . . . . . . . . . . . . . . . . . . . . . 18 | 4.3. Validation . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
4.3.1. Sending a Validation Request . . . . . . . . . . . . 18 | 4.3.1. Sending a Validation Request . . . . . . . . . . . . 19 | |||
4.3.2. Handling a Received Validation Request . . . . . . . 19 | 4.3.2. Handling a Received Validation Request . . . . . . . 19 | |||
4.3.3. Handling a Validation Response . . . . . . . . . . . 20 | 4.3.3. Handling a Validation Response . . . . . . . . . . . 21 | |||
4.3.4. Freshening Stored Responses upon Validation . . . . . 21 | 4.3.4. Freshening Stored Responses upon Validation . . . . . 21 | |||
4.3.5. Freshening Responses with HEAD . . . . . . . . . . . 21 | 4.3.5. Freshening Responses with HEAD . . . . . . . . . . . 22 | |||
4.4. Invalidating Stored Responses . . . . . . . . . . . . . . 22 | 4.4. Invalidating Stored Responses . . . . . . . . . . . . . . 22 | |||
5. Field Definitions . . . . . . . . . . . . . . . . . . . . . . 23 | 5. Field Definitions . . . . . . . . . . . . . . . . . . . . . . 23 | |||
5.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 | 5.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 | |||
5.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 23 | 5.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 24 | |||
5.2.1. Request Cache-Control Directives . . . . . . . . . . 24 | 5.2.1. Request Cache-Control Directives . . . . . . . . . . 24 | |||
5.2.2. Response Cache-Control Directives . . . . . . . . . . 26 | 5.2.2. Response Cache-Control Directives . . . . . . . . . . 26 | |||
5.2.3. Cache Control Extensions . . . . . . . . . . . . . . 30 | 5.2.3. Cache Control Extensions . . . . . . . . . . . . . . 31 | |||
5.2.4. Cache Directive Registry . . . . . . . . . . . . . . 31 | 5.2.4. Cache Directive Registry . . . . . . . . . . . . . . 32 | |||
5.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 31 | 5.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 32 | |||
5.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . 32 | 5.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . 33 | |||
5.5. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 33 | 5.5. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 33 | |||
6. Relationship to Applications and Other Caches . . . . . . . . 33 | 6. Relationship to Applications and Other Caches . . . . . . . . 33 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 34 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 34 | |||
7.1. Cache Poisoning . . . . . . . . . . . . . . . . . . . . . 34 | 7.1. Cache Poisoning . . . . . . . . . . . . . . . . . . . . . 35 | |||
7.2. Timing Attacks . . . . . . . . . . . . . . . . . . . . . 34 | 7.2. Timing Attacks . . . . . . . . . . . . . . . . . . . . . 35 | |||
7.3. Caching of Sensitive Information . . . . . . . . . . . . 35 | 7.3. Caching of Sensitive Information . . . . . . . . . . . . 35 | |||
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 | |||
8.1. Field Name Registration . . . . . . . . . . . . . . . . . 35 | 8.1. Field Name Registration . . . . . . . . . . . . . . . . . 36 | |||
8.2. Cache Directive Registration . . . . . . . . . . . . . . 35 | 8.2. Cache Directive Registration . . . . . . . . . . . . . . 36 | |||
8.3. Warn Code Registry . . . . . . . . . . . . . . . . . . . 36 | 8.3. Warn Code Registry . . . . . . . . . . . . . . . . . . . 37 | |||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 | |||
9.1. Normative References . . . . . . . . . . . . . . . . . . 36 | 9.1. Normative References . . . . . . . . . . . . . . . . . . 37 | |||
9.2. Informative References . . . . . . . . . . . . . . . . . 37 | 9.2. Informative References . . . . . . . . . . . . . . . . . 37 | |||
Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 38 | Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 38 | |||
Appendix B. Changes from RFC 7234 . . . . . . . . . . . . . . . 38 | Appendix B. Changes from RFC 7234 . . . . . . . . . . . . . . . 39 | |||
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 39 | Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 40 | |||
C.1. Between RFC7234 and draft 00 . . . . . . . . . . . . . . 39 | C.1. Between RFC7234 and draft 00 . . . . . . . . . . . . . . 40 | |||
C.2. Since draft-ietf-httpbis-cache-00 . . . . . . . . . . . . 39 | C.2. Since draft-ietf-httpbis-cache-00 . . . . . . . . . . . . 40 | |||
C.3. Since draft-ietf-httpbis-cache-01 . . . . . . . . . . . . 40 | C.3. Since draft-ietf-httpbis-cache-01 . . . . . . . . . . . . 40 | |||
C.4. Since draft-ietf-httpbis-cache-02 . . . . . . . . . . . . 40 | C.4. Since draft-ietf-httpbis-cache-02 . . . . . . . . . . . . 41 | |||
C.5. Since draft-ietf-httpbis-cache-03 . . . . . . . . . . . . 40 | C.5. Since draft-ietf-httpbis-cache-03 . . . . . . . . . . . . 41 | |||
C.6. Since draft-ietf-httpbis-cache-04 . . . . . . . . . . . . 41 | C.6. Since draft-ietf-httpbis-cache-04 . . . . . . . . . . . . 41 | |||
C.7. Since draft-ietf-httpbis-cache-05 . . . . . . . . . . . . 41 | C.7. Since draft-ietf-httpbis-cache-05 . . . . . . . . . . . . 42 | |||
C.8. Since draft-ietf-httpbis-cache-06 . . . . . . . . . . . . 41 | C.8. Since draft-ietf-httpbis-cache-06 . . . . . . . . . . . . 42 | |||
C.9. Since draft-ietf-httpbis-cache-07 . . . . . . . . . . . . 42 | C.9. Since draft-ietf-httpbis-cache-07 . . . . . . . . . . . . 43 | |||
C.10. Since draft-ietf-httpbis-cache-08 . . . . . . . . . . . . 42 | C.10. Since draft-ietf-httpbis-cache-08 . . . . . . . . . . . . 43 | |||
C.11. Since draft-ietf-httpbis-cache-09 . . . . . . . . . . . . 42 | C.11. Since draft-ietf-httpbis-cache-09 . . . . . . . . . . . . 43 | |||
C.12. Since draft-ietf-httpbis-cache-10 . . . . . . . . . . . . 42 | C.12. Since draft-ietf-httpbis-cache-10 . . . . . . . . . . . . 43 | |||
C.13. Since draft-ietf-httpbis-cache-11 . . . . . . . . . . . . 42 | C.13. Since draft-ietf-httpbis-cache-11 . . . . . . . . . . . . 43 | |||
C.14. Since draft-ietf-httpbis-cache-12 . . . . . . . . . . . . 42 | C.14. Since draft-ietf-httpbis-cache-12 . . . . . . . . . . . . 43 | |||
C.15. Since draft-ietf-httpbis-cache-13 . . . . . . . . . . . . 44 | C.15. Since draft-ietf-httpbis-cache-13 . . . . . . . . . . . . 45 | |||
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 44 | C.16. Since draft-ietf-httpbis-cache-14 . . . . . . . . . . . . 45 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 | Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 46 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 | ||||
1. Introduction | 1. Introduction | |||
The Hypertext Transfer Protocol (HTTP) is a stateless application- | The Hypertext Transfer Protocol (HTTP) is a stateless application- | |||
level request/response protocol that uses extensible semantics and | level request/response protocol that uses extensible semantics and | |||
self-descriptive messages for flexible interaction with network-based | self-descriptive messages for flexible interaction with network-based | |||
hypertext information systems. It is typically used for distributed | hypertext information systems. It is typically used for distributed | |||
information systems, where the use of response caches can improve | information systems, where the use of response caches can improve | |||
performance. This document defines aspects of HTTP related to | performance. This document defines aspects of HTTP related to | |||
caching and reusing response messages. | caching and reusing response messages. | |||
skipping to change at page 6, line 27 ¶ | skipping to change at page 6, line 27 ¶ | |||
([Semantics]) while reducing the transmission of information already | ([Semantics]) while reducing the transmission of information already | |||
held in the cache. Although caching is an entirely OPTIONAL feature | held in the cache. Although caching is an entirely OPTIONAL feature | |||
of HTTP, it can be assumed that reusing a cached response is | of HTTP, it can be assumed that reusing a cached response is | |||
desirable and that such reuse is the default behavior when no | desirable and that such reuse is the default behavior when no | |||
requirement or local configuration prevents it. Therefore, HTTP | requirement or local configuration prevents it. Therefore, HTTP | |||
cache requirements are focused on preventing a cache from either | cache requirements are focused on preventing a cache from either | |||
storing a non-reusable response or reusing a stored response | storing a non-reusable response or reusing a stored response | |||
inappropriately, rather than mandating that caches always store and | inappropriately, rather than mandating that caches always store and | |||
reuse particular responses. | reuse particular responses. | |||
The _cache key_ is comprised of, at a minimum, the request method and | The _cache key_ is the information a cache uses to select a response | |||
target URI used to retrieve the stored response; the method | and is comprised of, at a minimum, the request method and target URI | |||
determines under which circumstances that response can be used to | used to retrieve the stored response; the method determines under | |||
satisfy a subsequent request. However, many HTTP caches in common | which circumstances that response can be used to satisfy a subsequent | |||
use today only cache GET responses, and therefore only use the URI as | request. However, many HTTP caches in common use today only cache | |||
the cache key, forwarding other methods. | GET responses, and therefore only use the URI as the cache key, | |||
forwarding other methods. | ||||
If a request target is subject to content negotiation, the cache | If a request target is subject to content negotiation, the cache | |||
might store multiple responses for it. Caches differentiate these | might store multiple responses for it. Caches differentiate these | |||
responses by incorporating values of the original request's selecting | responses by incorporating values of the original request's selecting | |||
header fields into the cache key as well, using information in the | header fields into the cache key as well, using information in the | |||
Vary response header field, as per Section 4.1. | Vary response header field, as per Section 4.1. | |||
Caches might incorporate additional material into the cache key. For | Caches might incorporate additional material into the cache key. For | |||
example, user agent caches might include the referring site's | example, user agent caches might include the referring site's | |||
identity, thereby "double keying" the cache to avoid some privacy | identity, thereby "double keying" the cache to avoid some privacy | |||
skipping to change at page 7, line 18 ¶ | skipping to change at page 7, line 27 ¶ | |||
3. Storing Responses in Caches | 3. Storing Responses in Caches | |||
A cache MUST NOT store a response to a request unless: | A cache MUST NOT store a response to a request unless: | |||
o the request method is understood by the cache; | o the request method is understood by the cache; | |||
o the response status code is final (see Section 15 of [Semantics]); | o the response status code is final (see Section 15 of [Semantics]); | |||
o if the response status code is 206 or 304, or the "must- | o if the response status code is 206 or 304, or the "must- | |||
understand" cache directive (see Section 5.2.2.2) is present: the | understand" cache directive (see Section 5.2.2.3) is present: the | |||
cache understands the response status code; | cache understands the response status code; | |||
o the "no-store" cache directive is not present in the response (see | o the "no-store" cache directive is not present in the response (see | |||
Section 5.2.2.4); | Section 5.2.2.5); | |||
o if the cache is shared: the "private" response directive is either | o if the cache is shared: the "private" response directive is either | |||
not present or allows a shared cache to store a modified response; | not present or allows a shared cache to store a modified response; | |||
see Section 5.2.2.7); | see Section 5.2.2.7); | |||
o if the cache is shared: the Authorization header field is not | o if the cache is shared: the Authorization header field is not | |||
present in the request (see Section 11.6.2 of [Semantics]) or a | present in the request (see Section 11.6.2 of [Semantics]) or a | |||
response directive is present that explicitly allows shared | response directive is present that explicitly allows shared | |||
caching (see Section 3.5); and, | caching (see Section 3.5); and, | |||
o the response contains at least one of: | o the response contains at least one of: | |||
* a public response directive (see Section 5.2.2.6); | * a public response directive (see Section 5.2.2.9); | |||
* a private response directive, if the cache is not shared (see | * a private response directive, if the cache is not shared (see | |||
Section 5.2.2.7); | Section 5.2.2.7); | |||
* an Expires header field (see Section 5.3); | * an Expires header field (see Section 5.3); | |||
* a max-age response directive (see Section 5.2.2.9); | * a max-age response directive (see Section 5.2.2.1); | |||
* if the cache is shared: an s-maxage response directive (see | * if the cache is shared: an s-maxage response directive (see | |||
Section 5.2.2.10); | Section 5.2.2.10); | |||
* a Cache Control Extension that allows it to be cached (see | * a Cache Control Extension that allows it to be cached (see | |||
Section 5.2.3); or, | Section 5.2.3); or, | |||
* a status code that is defined as heuristically cacheable (see | * a status code that is defined as heuristically cacheable (see | |||
Section 4.2.2). | Section 4.2.2). | |||
Note that a cache-control extension can override any of the | Note that a cache-control extension can override any of the | |||
skipping to change at page 8, line 34 ¶ | skipping to change at page 8, line 42 ¶ | |||
o The Connection header field and fields whose names are listed in | o The Connection header field and fields whose names are listed in | |||
it are required by Section 7.6.1 of [Semantics] to be removed | it are required by Section 7.6.1 of [Semantics] to be removed | |||
before forwarding the message. This MAY be implemented by doing | before forwarding the message. This MAY be implemented by doing | |||
so before storage. | so before storage. | |||
o Likewise, some fields' semantics require them to be removed before | o Likewise, some fields' semantics require them to be removed before | |||
forwarding the message, and this MAY be implemented by doing so | forwarding the message, and this MAY be implemented by doing so | |||
before storage; see Section 7.6.1 of [Semantics] for some | before storage; see Section 7.6.1 of [Semantics] for some | |||
examples. | examples. | |||
o The no-cache (Section 5.2.2.3) and private (Section 5.2.2.7) cache | o The no-cache (Section 5.2.2.4) and private (Section 5.2.2.7) cache | |||
directives can have arguments that prevent storage of header | directives can have arguments that prevent storage of header | |||
fields by all caches and shared caches, respectively. | fields by all caches and shared caches, respectively. | |||
o Header fields that are specific to a client's proxy configuration | o Header fields that are specific to the proxy that a cache uses | |||
MUST NOT be stored, unless the cache incorporates the identity of | when forwarding a request MUST NOT be stored, unless the cache | |||
the proxy into the cache key. Effectively, this is limited to | incorporates the identity of the proxy into the cache key. | |||
Proxy-Authenticate (Section 11.7.1 of [Semantics]), Proxy- | Effectively, this is limited to Proxy-Authenticate (Section 11.7.1 | |||
Authentication-Info (Section 11.7.3 of [Semantics]), and Proxy- | of [Semantics]), Proxy-Authentication-Info (Section 11.7.3 of | |||
Authorization (Section 11.7.2 of [Semantics]). | [Semantics]), and Proxy-Authorization (Section 11.7.2 of | |||
[Semantics]). | ||||
Caches MAY either store trailer fields separate from header fields, | Caches MAY either store trailer fields separate from header fields, | |||
or discard them. Caches MUST NOT combine trailer fields with header | or discard them. Caches MUST NOT combine trailer fields with header | |||
fields. | fields. | |||
3.2. Updating Stored Header Fields | 3.2. Updating Stored Header Fields | |||
Caches are required to update a stored response's header fields from | Caches are required to update a stored response's header fields from | |||
another (typically newer) response in several situations; for | another (typically newer) response in several situations; for | |||
example, see Section 3.4, Section 4.3.4 and Section 4.3.5. | example, see Section 3.4, Section 4.3.4 and Section 4.3.5. | |||
skipping to change at page 11, line 6 ¶ | skipping to change at page 11, line 30 ¶ | |||
3.5. Storing Responses to Authenticated Requests | 3.5. 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 11.6.2 of [Semantics]) to satisfy | Authorization header field (Section 11.6.2 of [Semantics]) to satisfy | |||
any subsequent request unless the response contains a Cache-Control | any subsequent request unless the response contains a Cache-Control | |||
field with a response directive (Section 5.2.2) that allows it to be | field with a response directive (Section 5.2.2) that allows it to be | |||
stored by a shared cache and the cache conforms to the requirements | stored by a shared cache and the cache conforms to the requirements | |||
of that directive for that response. | of that directive for that response. | |||
In this specification, the following response directives have such an | In this specification, the following response directives have such an | |||
effect: must-revalidate (Section 5.2.2.1), public (Section 5.2.2.6), | effect: must-revalidate (Section 5.2.2.2), public (Section 5.2.2.9), | |||
and s-maxage (Section 5.2.2.10). | and s-maxage (Section 5.2.2.10). | |||
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: | |||
o The presented target URI (Section 7.1 of [Semantics]) and that of | o The presented target URI (Section 7.1 of [Semantics]) and that of | |||
the stored response match, and | the stored response match, and | |||
o the request method associated with the stored response allows it | o the request method associated with the stored response allows it | |||
to be used for the presented request, and | to be used for the presented request, and | |||
o selecting header fields nominated by the stored response (if any) | o selecting header fields nominated by the stored response (if any) | |||
match those presented (see Section 4.1), and | match those presented (see Section 4.1), and | |||
o the stored response does not contain the no-cache cache directive | o the stored response does not contain the no-cache cache directive | |||
(Section 5.2.2.3), unless it is successfully validated | (Section 5.2.2.4), unless it is successfully validated | |||
(Section 4.3), and | (Section 4.3), and | |||
o the stored response is either: | o the stored response is either: | |||
* fresh (see Section 4.2), or | * fresh (see Section 4.2), or | |||
* allowed to be served stale (see Section 4.2.4), or | * allowed to be served stale (see Section 4.2.4), or | |||
* successfully validated (see Section 4.3). | * successfully validated (see Section 4.3). | |||
skipping to change at page 14, line 8 ¶ | skipping to change at page 14, line 28 ¶ | |||
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, it can be used to satisfy subsequent | When a response is fresh, it can be used to satisfy subsequent | |||
requests without contacting the origin server, thereby improving | requests without contacting the origin server, thereby improving | |||
efficiency. | 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 | |||
directive (Section 5.2.2.9). Generally, origin servers will assign | directive (Section 5.2.2.1). Generally, origin servers will assign | |||
future explicit expiration times to responses in the belief that the | future explicit expiration times to responses in the belief that the | |||
representation is not likely to change in a semantically significant | representation is not likely to change in a semantically 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). | |||
skipping to change at page 15, line 18 ¶ | skipping to change at page 15, line 39 ¶ | |||
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 directive | o If the cache is shared and the s-maxage response directive | |||
(Section 5.2.2.10) is present, use its value, or | (Section 5.2.2.10) is present, use its value, or | |||
o If the max-age response directive (Section 5.2.2.9) is present, | o If the max-age response directive (Section 5.2.2.1) is 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 (using | its value minus the value of the Date response header field (using | |||
the time the message was received if it is not present, as per | the time the message was received if it is not present, as per | |||
Section 10.2.2 of [Semantics]), or | Section 10.2.2 of [Semantics]), 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. | |||
skipping to change at page 23, line 23 ¶ | skipping to change at page 23, line 46 ¶ | |||
time since the response was generated or successfully validated at | time since the response was generated or successfully validated at | |||
the origin server. Age values are calculated as specified in | the origin server. Age values are calculated as specified in | |||
Section 4.2.3. | Section 4.2.3. | |||
Age = delta-seconds | Age = delta-seconds | |||
The Age field value is a non-negative integer, representing time in | The Age field value is a non-negative integer, representing time in | |||
seconds (see Section 1.3). | seconds (see Section 1.3). | |||
Although it is defined as a singleton header field, a cache | Although it is defined as a singleton header field, a cache | |||
encountering a message with multiple Age field lines SHOULD use the | encountering a message with a list-based Age field value SHOULD use | |||
first field line, discarding subsequent ones. | the first member of the field value, discarding subsequent ones. | |||
If the field value (after discarding additional lines, as per above) | If the field value (after discarding additional members, as per | |||
is invalid (e.g., it contains a list or something other than a non- | above) is invalid (e.g., it contains something other than a non- | |||
negative integer), a cache SHOULD consider the response to be stale. | negative integer), a cache SHOULD ignore the field. | |||
The presence of an Age header field implies that the response was not | The presence of an Age header field implies that the response was not | |||
generated or validated by the origin server for this request. | generated or validated by the origin server for this request. | |||
However, lack of an Age header field does not imply the origin was | However, lack of an Age header field does not imply the origin was | |||
contacted. | contacted. | |||
5.2. Cache-Control | 5.2. Cache-Control | |||
The "Cache-Control" header field is used to list directives for | The "Cache-Control" header field is used to list directives for | |||
caches along the request/response chain. Such cache directives are | caches along the request/response chain. Such cache directives are | |||
skipping to change at page 26, line 24 ¶ | skipping to change at page 26, line 43 ¶ | |||
wishes to obtain a stored response. Caches that honor this request | wishes to obtain a stored response. Caches that honor this request | |||
directive SHOULD, upon receiving it, either respond using a stored | directive SHOULD, upon receiving it, either respond using a stored | |||
response consistent with the other constraints of the request, or | response consistent with the other constraints of the request, or | |||
respond with a 504 (Gateway Timeout) status code. | respond with a 504 (Gateway Timeout) status code. | |||
5.2.2. Response Cache-Control Directives | 5.2.2. Response Cache-Control Directives | |||
This section defines cache response directives. A cache MUST obey | This section defines cache response directives. A cache MUST obey | |||
the Cache-Control directives defined in this section. | the Cache-Control directives defined in this section. | |||
5.2.2.1. must-revalidate | 5.2.2.1. max-age | |||
Argument syntax: | ||||
delta-seconds (see Section 1.3) | ||||
The "max-age" response directive indicates that the response is to be | ||||
considered stale after its age is greater than the specified number | ||||
of seconds. | ||||
This directive uses the token form of the argument syntax: e.g., | ||||
'max-age=5' not 'max-age="5"'. A sender MUST NOT generate the | ||||
quoted-string form. | ||||
5.2.2.2. must-revalidate | ||||
The "must-revalidate" response directive indicates that once the | The "must-revalidate" response directive indicates that once the | |||
response has become stale, a cache MUST NOT reuse that response to | response has become stale, a cache MUST NOT reuse that response to | |||
satisfy another request until it has been successfully validated by | satisfy another request until it has been successfully validated by | |||
the origin, as defined by Section 4.3. | the origin, as defined by Section 4.3. | |||
The must-revalidate directive is necessary to support reliable | The must-revalidate directive is necessary to support reliable | |||
operation for certain protocol features. In all circumstances a | operation for certain protocol features. In all circumstances a | |||
cache MUST NOT ignore the must-revalidate directive; in particular, | cache MUST NOT ignore the must-revalidate directive; in particular, | |||
if a cache is disconnected, the cache MUST generate an error response | if a cache is disconnected, the cache MUST generate an error response | |||
skipping to change at page 26, line 48 ¶ | skipping to change at page 27, line 33 ¶ | |||
The must-revalidate directive ought to be used by servers if and only | The must-revalidate directive ought to be used by servers if and only | |||
if failure to validate a request could cause incorrect operation, | if failure to validate a request could cause incorrect operation, | |||
such as a silently unexecuted financial transaction. | such as a silently unexecuted financial transaction. | |||
The must-revalidate directive also permits a shared cache to reuse a | The must-revalidate directive also permits a shared cache to reuse a | |||
response to a request containing an Authorization header field | response to a request containing an Authorization header field | |||
(Section 11.6.2 of [Semantics]), subject to the above requirement on | (Section 11.6.2 of [Semantics]), subject to the above requirement on | |||
revalidation (Section 3.5). | revalidation (Section 3.5). | |||
5.2.2.2. must-understand | 5.2.2.3. must-understand | |||
The "must-understand" response directive limits caching of the | The "must-understand" response directive limits caching of the | |||
response to a cache that understands and conforms to the requirements | response to a cache that understands and conforms to the requirements | |||
for that response's status code. | for that response's status code. | |||
Responses containing "must-understand" SHOULD also contain the "no- | Responses containing "must-understand" SHOULD also contain the "no- | |||
store" directive; caches that implement "must-understand" SHOULD | store" directive; caches that implement "must-understand" SHOULD | |||
ignore the "no-store" directive in responses that contain both | ignore the "no-store" directive in responses that contain both | |||
directives and a status code that the cache understands and conforms | directives and a status code that the cache understands and conforms | |||
to any related caching requirements. | to any related caching requirements. | |||
5.2.2.3. no-cache | 5.2.2.4. no-cache | |||
Argument syntax: | Argument syntax: | |||
#field-name | #field-name | |||
The "no-cache" response directive, in its unqualified form (without | The "no-cache" response directive, in its unqualified form (without | |||
an argument), indicates that the response MUST NOT be used to satisfy | an argument), indicates that the response MUST NOT be used to satisfy | |||
any other request without forwarding it for validation and receiving | any other request without forwarding it for validation and receiving | |||
a successful response; see Section 4.3. | a successful response; see Section 4.3. | |||
skipping to change at page 27, line 48 ¶ | skipping to change at page 28, line 36 ¶ | |||
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:* The qualified form of the directive is often handled by | | *Note:* The qualified form of the directive is often handled by | |||
| caches as if an unqualified no-cache directive was received; | | caches as if an unqualified no-cache directive was received; | |||
| i.e., the special handling for the qualified form is not widely | | i.e., the special handling for the qualified form is not widely | |||
| implemented. | | implemented. | |||
5.2.2.4. no-store | 5.2.2.5. 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, and MUST | store any part of either the immediate request or response, and MUST | |||
NOT use the response to satisfy any other request. | NOT use the response to satisfy any other request. | |||
This directive applies to both private and shared caches. "MUST NOT | This directive applies to both private and shared caches. "MUST NOT | |||
store" in this context means that the cache MUST NOT intentionally | store" in this context means that the cache MUST NOT intentionally | |||
store the information in non-volatile storage, and MUST make a best- | store the information in non-volatile storage, and MUST make a best- | |||
effort attempt to remove the information from volatile storage as | effort attempt to remove the information from volatile storage as | |||
promptly as possible after forwarding it. | promptly as possible after forwarding it. | |||
This directive is _not_ a reliable or sufficient mechanism for | This directive is _not_ a reliable or sufficient mechanism for | |||
ensuring privacy. In particular, malicious or compromised caches | ensuring privacy. In particular, malicious or compromised caches | |||
might not recognize or obey this directive, and communications | might not recognize or obey this directive, and communications | |||
networks might be vulnerable to eavesdropping. | networks might be vulnerable to eavesdropping. | |||
Note that the "must-understand" cache directive overrides "no-store" | Note that the "must-understand" cache directive overrides "no-store" | |||
in certain circumstances; see Section 5.2.2.2. | in certain circumstances; see Section 5.2.2.3. | |||
5.2.2.5. no-transform | 5.2.2.6. 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 | |||
content, as defined in Section 7.7 of [Semantics]. | content, as defined in Section 7.7 of [Semantics]. | |||
5.2.2.6. public | ||||
The "public" response directive indicates that a cache MAY store the | ||||
response even if it would otherwise be prohibited, subject to the | ||||
constraints defined in Section 3. In other words, public explicitly | ||||
marks the response as cacheable. For example, public permits a | ||||
shared cache to reuse a response to a request containing an | ||||
Authorization header field (Section 3.5). | ||||
Note that it is unnecessary to add the public directive to a response | ||||
that is already cacheable according to Section 3. | ||||
If a response with the public directive has no explicit freshness | ||||
information, it is heuristically cacheable (Section 4.2.2). | ||||
5.2.2.7. private | 5.2.2.7. private | |||
Argument syntax: | Argument syntax: | |||
#field-name | #field-name | |||
The unqualified "private" response directive indicates that a shared | The unqualified "private" response directive indicates that a shared | |||
cache MUST NOT store the response (i.e., the response is intended for | cache MUST NOT store the response (i.e., the response is intended for | |||
a single user). It also indicates that a private cache MAY store the | a single user). It also indicates that a private cache MAY store the | |||
response, subject the constraints defined in Section 3, even if the | response, subject the constraints defined in Section 3, even if the | |||
skipping to change at page 29, line 32 ¶ | skipping to change at page 30, line 11 ¶ | |||
| often handled by caches as if an unqualified private directive | | often handled by caches as if an unqualified private directive | |||
| was received; i.e., the special handling for the qualified form | | was received; i.e., the special handling for the qualified form | |||
| is not widely implemented. | | is not widely implemented. | |||
5.2.2.8. proxy-revalidate | 5.2.2.8. proxy-revalidate | |||
The "proxy-revalidate" response directive indicates that once the | The "proxy-revalidate" response directive indicates that once the | |||
response has become stale, a shared cache MUST NOT reuse that | response has become stale, a shared cache MUST NOT reuse that | |||
response to satisfy another request until it has been successfully | response to satisfy another request until it has been successfully | |||
validated by the origin, as defined by Section 4.3. This is | validated by the origin, as defined by Section 4.3. This is | |||
analogous to must-revalidate (Section 5.2.2.1), except that proxy- | analogous to must-revalidate (Section 5.2.2.2), except that proxy- | |||
revalidate does not apply to private caches. | revalidate does not apply to private caches. | |||
Note that "proxy-revalidate" on its own does not imply that a | Note that "proxy-revalidate" on its own does not imply that a | |||
response is cacheable. For example, it might be combined with the | response is cacheable. For example, it might be combined with the | |||
public directive (Section 5.2.2.6), allowing the response to be | public directive (Section 5.2.2.9), allowing the response to be | |||
cached while requiring only a shared cache to revalidate when stale. | cached while requiring only a shared cache to revalidate when stale. | |||
5.2.2.9. max-age | 5.2.2.9. public | |||
Argument syntax: | ||||
delta-seconds (see Section 1.3) | The "public" response directive indicates that a cache MAY store the | |||
response even if it would otherwise be prohibited, subject to the | ||||
constraints defined in Section 3. In other words, public explicitly | ||||
marks the response as cacheable. For example, public permits a | ||||
shared cache to reuse a response to a request containing an | ||||
Authorization header field (Section 3.5). | ||||
The "max-age" response directive indicates that the response is to be | Note that it is unnecessary to add the public directive to a response | |||
considered stale after its age is greater than the specified number | that is already cacheable according to Section 3. | |||
of seconds. | ||||
This directive uses the token form of the argument syntax: e.g., | If a response with the public directive has no explicit freshness | |||
'max-age=5' not 'max-age="5"'. A sender MUST NOT generate the | information, it is heuristically cacheable (Section 4.2.2). | |||
quoted-string form. | ||||
5.2.2.10. s-maxage | 5.2.2.10. s-maxage | |||
Argument syntax: | Argument syntax: | |||
delta-seconds (see Section 1.3) | delta-seconds (see Section 1.3) | |||
The "s-maxage" response directive indicates that, for a shared cache, | The "s-maxage" response directive indicates that, for a shared cache, | |||
the maximum age specified by this directive overrides the maximum age | the maximum age specified by this directive overrides the maximum age | |||
specified by either the max-age directive or the Expires header | specified by either the max-age directive or the Expires header | |||
skipping to change at page 32, line 10 ¶ | skipping to change at page 32, line 35 ¶ | |||
The "Expires" response header field gives the date/time after which | The "Expires" response header field gives the date/time after which | |||
the response is considered stale. See Section 4.2 for further | the response is considered stale. See Section 4.2 for further | |||
discussion of the freshness model. | discussion of the freshness model. | |||
The presence of an Expires header field does not imply that the | The presence of an Expires header field does not imply that the | |||
original resource will change or cease to exist at, before, or after | original resource will change or cease to exist at, before, or after | |||
that time. | that time. | |||
The Expires field value is an HTTP-date timestamp, as defined in | The Expires field value is an HTTP-date timestamp, as defined in | |||
Section 5.6.7 of [Semantics]. | Section 5.6.7 of [Semantics]. See also Section 4.2 for parsing | |||
requirements specific to caches. | ||||
Expires = HTTP-date | Expires = HTTP-date | |||
For example | For example | |||
Expires: Thu, 01 Dec 1994 16:00:00 GMT | Expires: Thu, 01 Dec 1994 16:00:00 GMT | |||
A cache recipient MUST interpret invalid date formats, especially the | A cache recipient MUST interpret invalid date formats, especially the | |||
value "0", as representing a time in the past (i.e., "already | value "0", as representing a time in the past (i.e., "already | |||
expired"). | expired"). | |||
If a response includes a Cache-Control header field with the max-age | If a response includes a Cache-Control header field with the max-age | |||
directive (Section 5.2.2.9), a recipient MUST ignore the Expires | directive (Section 5.2.2.1), a recipient MUST ignore the Expires | |||
header field. Likewise, if a response includes the s-maxage | header field. Likewise, if a response includes the s-maxage | |||
directive (Section 5.2.2.10), a shared cache recipient MUST ignore | directive (Section 5.2.2.10), a shared cache recipient MUST ignore | |||
the Expires header field. In both these cases, the value in Expires | the Expires header field. In both these cases, the value in Expires | |||
is only intended for recipients that have not yet implemented the | is only intended for recipients that have not yet implemented the | |||
Cache-Control header field. | Cache-Control header field. | |||
An origin server without a clock MUST NOT generate an Expires header | An origin server without a clock MUST NOT generate an Expires header | |||
field unless its value represents a fixed time in the past (always | field unless its value represents a fixed time in the past (always | |||
expired) or its value has been associated with the resource by a | expired) or its value has been associated with the resource by a | |||
system or user with a reliable clock. | system or user with a reliable clock. | |||
skipping to change at page 34, line 23 ¶ | skipping to change at page 35, line 7 ¶ | |||
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. | |||
7.1. Cache Poisoning | 7.1. Cache Poisoning | |||
Various attacks might be amplified by being stored in a shared cache. | Various attacks might be amplified by being stored in a cache. Such | |||
Such "cache poisoning" attacks use the cache to distribute malicious | "cache poisoning" attacks happen when an attacker uses implementation | |||
content to many clients, and are especially effective when an | flaws, elevated privileges, or other techniques to insert a response | |||
attacker can use implementation flaws, elevated privileges, or other | into a cache. This is especially effective when shared caches are | |||
techniques to insert such a response into a cache. | used to distribute malicious content to many clients. | |||
One common attack vector for cache poisoning is to exploit | One common attack vector for cache poisoning is to exploit | |||
differences in message parsing on proxies and in user agents; see | differences in message parsing on proxies and in user agents; see | |||
Section 6.3 of [Messaging] for the relevant requirements regarding | Section 6.3 of [Messaging] for the relevant requirements regarding | |||
HTTP/1.1. | HTTP/1.1. | |||
7.2. Timing Attacks | 7.2. Timing Attacks | |||
Because one of the primary uses of a cache is to optimise | Because one of the primary uses of a cache is to optimise | |||
performance, its use can "leak" information about what resources have | performance, its use can "leak" information about what resources have | |||
skipping to change at page 36, line 8 ¶ | skipping to change at page 36, line 36 ¶ | |||
8.2. Cache Directive Registration | 8.2. Cache Directive Registration | |||
Please update the "Hypertext Transfer Protocol (HTTP) Cache Directive | Please update the "Hypertext Transfer Protocol (HTTP) Cache Directive | |||
Registry" at <https://www.iana.org/assignments/http-cache-directives> | Registry" at <https://www.iana.org/assignments/http-cache-directives> | |||
with the registration procedure of Section 5.2.4 and the cache | with the registration procedure of Section 5.2.4 and the cache | |||
directive names summarized in the table below. | directive names summarized in the table below. | |||
+------------------+----------------------------------+ | +------------------+----------------------------------+ | |||
| Cache Directive | Reference | | | Cache Directive | Reference | | |||
+------------------+----------------------------------+ | +------------------+----------------------------------+ | |||
| max-age | Section 5.2.1.1, Section 5.2.2.9 | | | max-age | Section 5.2.1.1, Section 5.2.2.1 | | |||
| max-stale | Section 5.2.1.2 | | | max-stale | Section 5.2.1.2 | | |||
| min-fresh | Section 5.2.1.3 | | | min-fresh | Section 5.2.1.3 | | |||
| must-revalidate | Section 5.2.2.1 | | | must-revalidate | Section 5.2.2.2 | | |||
| must-understand | Section 5.2.2.2 | | | must-understand | Section 5.2.2.3 | | |||
| no-cache | Section 5.2.1.4, Section 5.2.2.3 | | | no-cache | Section 5.2.1.4, Section 5.2.2.4 | | |||
| no-store | Section 5.2.1.5, Section 5.2.2.4 | | | no-store | Section 5.2.1.5, Section 5.2.2.5 | | |||
| no-transform | Section 5.2.1.6, Section 5.2.2.5 | | | no-transform | Section 5.2.1.6, Section 5.2.2.6 | | |||
| only-if-cached | Section 5.2.1.7 | | | only-if-cached | Section 5.2.1.7 | | |||
| private | Section 5.2.2.7 | | | private | Section 5.2.2.7 | | |||
| proxy-revalidate | Section 5.2.2.8 | | | proxy-revalidate | Section 5.2.2.8 | | |||
| public | Section 5.2.2.6 | | | public | Section 5.2.2.9 | | |||
| s-maxage | Section 5.2.2.10 | | | s-maxage | Section 5.2.2.10 | | |||
+------------------+----------------------------------+ | +------------------+----------------------------------+ | |||
Table 2 | Table 2 | |||
8.3. Warn Code Registry | 8.3. Warn Code Registry | |||
Please add a note to the "Hypertext Transfer Protocol (HTTP) Warn | Please add a note to the "Hypertext Transfer Protocol (HTTP) Warn | |||
Codes" registry at <https://www.iana.org/assignments/http-warn-codes> | Codes" registry at <https://www.iana.org/assignments/http-warn-codes> | |||
to the effect that Warning is obsoleted. | to the effect that Warning is obsoleted. | |||
9. References | 9. References | |||
9.1. Normative References | 9.1. Normative References | |||
[Messaging] | [Messaging] | |||
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, | Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, | |||
Ed., "HTTP/1.1", Work in Progress, Internet-Draft, draft- | Ed., "HTTP/1.1", Work in Progress, Internet-Draft, draft- | |||
ietf-httpbis-messaging-latest, January 2021, | ietf-httpbis-messaging-latest, February 2021, | |||
<https://tools.ietf.org/html/draft-ietf-httpbis-messaging- | <https://tools.ietf.org/html/draft-ietf-httpbis-messaging- | |||
latest>. | latest>. | |||
[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, | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
<https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
[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, | Specifications: ABNF", STD 68, RFC 5234, | |||
skipping to change at page 37, line 16 ¶ | skipping to change at page 37, line 43 ¶ | |||
RFC 7405, DOI 10.17487/RFC7405, December 2014, | RFC 7405, DOI 10.17487/RFC7405, December 2014, | |||
<https://www.rfc-editor.org/info/rfc7405>. | <https://www.rfc-editor.org/info/rfc7405>. | |||
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | |||
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | |||
May 2017, <https://www.rfc-editor.org/info/rfc8174>. | May 2017, <https://www.rfc-editor.org/info/rfc8174>. | |||
[Semantics] | [Semantics] | |||
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, | Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, | |||
Ed., "HTTP Semantics", Work in Progress, Internet-Draft, | Ed., "HTTP Semantics", Work in Progress, Internet-Draft, | |||
draft-ietf-httpbis-semantics-latest, January 2021, | draft-ietf-httpbis-semantics-latest, February 2021, | |||
<https://tools.ietf.org/html/draft-ietf-httpbis-semantics- | <https://tools.ietf.org/html/draft-ietf-httpbis-semantics- | |||
latest>. | latest>. | |||
9.2. Informative References | 9.2. Informative References | |||
[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, | Transfer Protocol -- HTTP/1.1", RFC 2616, | |||
DOI 10.17487/RFC2616, June 1999, | DOI 10.17487/RFC2616, June 1999, | |||
<https://www.rfc-editor.org/info/rfc2616>. | <https://www.rfc-editor.org/info/rfc2616>. | |||
skipping to change at page 39, line 4 ¶ | skipping to change at page 39, line 47 ¶ | |||
Handling invalid and multiple Age header field values has been | Handling invalid and multiple Age header field values has been | |||
clarified. (Section 5.1) | clarified. (Section 5.1) | |||
Some cache directives defined by this specification now have stronger | Some cache directives defined by this specification now have stronger | |||
prohibitions against generating the quoted form of their values, | prohibitions against generating the quoted form of their values, | |||
since this has been found to create interoperability problems. | since this has been found to create interoperability problems. | |||
Consumers of extension cache directives are no longer required to | Consumers of extension cache directives are no longer required to | |||
accept both token and quoted-string forms, but they still need to | accept both token and quoted-string forms, but they still need to | |||
parse them properly for unknown extensions. (Section 5.2) | parse them properly for unknown extensions. (Section 5.2) | |||
The "public" and "private" cache directives were clarified, so that | The "public" and "private" cache directives were clarified, so that | |||
they do not make responses reusable under any condition. | they do not make responses reusable under any condition. | |||
(Section 5.2.2) | (Section 5.2.2) | |||
The "must-understand" cache directive was introduced; caches are no | The "must-understand" cache directive was introduced; caches are no | |||
longer required to understand the semantics of new response status | longer required to understand the semantics of new response status | |||
codes unless it is present. (Section 5.2.2.2) | codes unless it is present. (Section 5.2.2.3) | |||
The Warning response header was obsoleted. Much of the information | The Warning response header was obsoleted. Much of the information | |||
supported by Warning could be gleaned by examining the response, and | supported by Warning could be gleaned by examining the response, and | |||
the remaining warn-codes - although potentially useful - were | the remaining warn-codes - although potentially useful - were | |||
entirely advisory. In practice, Warning was not added by caches or | entirely advisory. In practice, Warning was not added by caches or | |||
intermediaries. (Section 5.5) | intermediaries. (Section 5.5) | |||
Appendix C. Change Log | Appendix C. Change Log | |||
This section is to be removed before publishing as an RFC. | This section is to be removed before publishing as an RFC. | |||
skipping to change at page 41, line 36 ¶ | skipping to change at page 42, line 29 ¶ | |||
<https://www.rfc-editor.org/errata/eid5300>) | <https://www.rfc-editor.org/errata/eid5300>) | |||
o Refactored Section 7, and added a section on timing attacks | o Refactored Section 7, and added a section on timing attacks | |||
(<https://github.com/httpwg/http-core/issues/233>) | (<https://github.com/httpwg/http-core/issues/233>) | |||
o Changed "cacheable by default" to "heuristically cacheable" | o Changed "cacheable by default" to "heuristically cacheable" | |||
throughout (<https://github.com/httpwg/http-core/issues/242>) | throughout (<https://github.com/httpwg/http-core/issues/242>) | |||
C.8. Since draft-ietf-httpbis-cache-06 | C.8. Since draft-ietf-httpbis-cache-06 | |||
o In Section 3 and Section 5.2.2.2, change response cacheability to | o In Section 3 and Section 5.2.2.3, change response cacheability to | |||
only require understanding the response status code if the must- | only require understanding the response status code if the must- | |||
understand cache directive is present (<https://github.com/httpwg/ | understand cache directive is present (<https://github.com/httpwg/ | |||
http-core/issues/120>) | http-core/issues/120>) | |||
o Change requirements for handling different forms of cache | o Change requirements for handling different forms of cache | |||
directives in Section 5.2 (<https://github.com/httpwg/http-core/ | directives in Section 5.2 (<https://github.com/httpwg/http-core/ | |||
issues/128>) | issues/128>) | |||
o Fix typo in Section 5.2.2.10 (<https://github.com/httpwg/http- | o Fix typo in Section 5.2.2.10 (<https://github.com/httpwg/http- | |||
core/issues/264>) | core/issues/264>) | |||
o In Section 5.2.2.6 and Section 5.2.2.7, clarify "private" and | o In Section 5.2.2.9 and Section 5.2.2.7, clarify "private" and | |||
"public" so that they do not override all other cache directives | "public" so that they do not override all other cache directives | |||
(<https://github.com/httpwg/http-core/issues/268>) | (<https://github.com/httpwg/http-core/issues/268>) | |||
o In Section 3, distinguish between private with and without | o In Section 3, distinguish between private with and without | |||
qualifying headers (<https://github.com/httpwg/http-core/ | qualifying headers (<https://github.com/httpwg/http-core/ | |||
issues/270>) | issues/270>) | |||
o In Section 4.1, clarify that any "*" as a member of Vary will | o In Section 4.1, clarify that any "*" as a member of Vary will | |||
disable caching (<https://github.com/httpwg/http-core/issues/286>) | disable caching (<https://github.com/httpwg/http-core/issues/286>) | |||
o In Section 1.1, reference RFC 8174 as well | o In Section 1.1, reference RFC 8174 as well | |||
(<https://github.com/httpwg/http-core/issues/303>) | (<https://github.com/httpwg/http-core/issues/303>) | |||
C.9. Since draft-ietf-httpbis-cache-07 | C.9. Since draft-ietf-httpbis-cache-07 | |||
o Throughout, replace "effective request URI", "request-target" and | o Throughout, replace "effective request URI", "request-target" and | |||
similar with "target URI" (<https://github.com/httpwg/http-core/ | similar with "target URI" (<https://github.com/httpwg/http-core/ | |||
issues/259>) | issues/259>) | |||
o In Section 5.2.2.6 and Section 5.2.2.7, make it clear that these | o In Section 5.2.2.9 and Section 5.2.2.7, make it clear that these | |||
directives do not ignore other requirements for caching | directives do not ignore other requirements for caching | |||
(<https://github.com/httpwg/http-core/issues/320>) | (<https://github.com/httpwg/http-core/issues/320>) | |||
o In Section 3.3, move definition of "complete" into semantics | o In Section 3.3, move definition of "complete" into semantics | |||
(<https://github.com/httpwg/http-core/issues/334>) | (<https://github.com/httpwg/http-core/issues/334>) | |||
C.10. Since draft-ietf-httpbis-cache-08 | C.10. Since draft-ietf-httpbis-cache-08 | |||
o Appendix A now uses the sender variant of the "#" list expansion | o Appendix A now uses the sender variant of the "#" list expansion | |||
(<https://github.com/httpwg/http-core/issues/192>) | (<https://github.com/httpwg/http-core/issues/192>) | |||
skipping to change at page 44, line 14 ¶ | skipping to change at page 45, line 14 ¶ | |||
o Changed to using "payload data" when defining requirements about | o Changed to using "payload data" when defining requirements about | |||
the data being conveyed within a message, instead of the terms | the data being conveyed within a message, instead of the terms | |||
"payload body" or "response body" or "representation body", since | "payload body" or "response body" or "representation body", since | |||
they often get confused with the HTTP/1.1 message body (which | they often get confused with the HTTP/1.1 message body (which | |||
includes transfer coding) (<https://github.com/httpwg/http-core/ | includes transfer coding) (<https://github.com/httpwg/http-core/ | |||
issues/553>) | issues/553>) | |||
C.15. Since draft-ietf-httpbis-cache-13 | C.15. Since draft-ietf-httpbis-cache-13 | |||
o In Section 5.2.2.1, clarify requirements around generating an | o In Section 5.2.2.2, clarify requirements around generating an | |||
error response (<https://github.com/httpwg/http-core/issues/608>) | error response (<https://github.com/httpwg/http-core/issues/608>) | |||
o Changed to using "content" instead of "payload" or "payload data" | o Changed to using "content" instead of "payload" or "payload data" | |||
to avoid confusion with the payload of version-specific messaging | to avoid confusion with the payload of version-specific messaging | |||
frames (<https://github.com/httpwg/http-core/issues/654>) | frames (<https://github.com/httpwg/http-core/issues/654>) | |||
o In Section 4.3.4, clarify how multiple validators are handled | o In Section 4.3.4, clarify how multiple validators are handled | |||
(<https://github.com/httpwg/http-core/issues/659>) | (<https://github.com/httpwg/http-core/issues/659>) | |||
o In Section 4.2.3, Section 5.2, and Section 5.2.2.3, remove notes | o In Section 4.2.3, Section 5.2, and Section 5.2.2.4, remove notes | |||
about very old HTTP/1.0 behaviours (<https://github.com/httpwg/ | about very old HTTP/1.0 behaviours (<https://github.com/httpwg/ | |||
http-core/issues/660>) | http-core/issues/660>) | |||
o In Section 5.2.2.2, modify operation to be more backwards- | o In Section 5.2.2.3, modify operation to be more backwards- | |||
compatible with existing implementations | compatible with existing implementations | |||
(<https://github.com/httpwg/http-core/issues/661>) | (<https://github.com/httpwg/http-core/issues/661>) | |||
C.16. Since draft-ietf-httpbis-cache-14 | ||||
o Fix subsection ordering in Section 5.2.2 | ||||
(<https://github.com/httpwg/http-core/issues/674>) | ||||
o In Section 2, define what a cache key is | ||||
(<https://github.com/httpwg/http-core/issues/728>) | ||||
o In Section 3.1, clarify what cache proxy headers apply to | ||||
(<https://github.com/httpwg/http-core/issues/729>) | ||||
o In Section 7.1, cache poisoning can affect private caches too | ||||
(<https://github.com/httpwg/http-core/issues/730>) | ||||
o In Section 5.1, adjust handling of invalid values to match most | ||||
deployed caches (<https://github.com/httpwg/http-core/issues/778>) | ||||
o In Section 5.3, mention parsing requirement relaxation | ||||
(<https://github.com/httpwg/http-core/issues/779>) | ||||
Acknowledgments | Acknowledgments | |||
See Appendix "Acknowledgments" of [Semantics]. | See Appendix "Acknowledgments" of [Semantics]. | |||
Authors' Addresses | Authors' Addresses | |||
Roy T. Fielding (editor) | Roy T. Fielding (editor) | |||
Adobe | Adobe | |||
345 Park Ave | 345 Park Ave | |||
San Jose, CA 95110 | San Jose, CA 95110 | |||
End of changes. 62 change blocks. | ||||
127 lines changed or deleted | 150 lines changed or added | |||
This html diff was produced by rfcdiff 1.44jr. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |