draft-ietf-httpbis-cache-07.txt   draft-ietf-httpbis-cache-08.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: September 8, 2020 J. Reschke, Ed. Expires: November 27, 2020 J. Reschke, Ed.
greenbytes greenbytes
March 7, 2020 May 26, 2020
HTTP Caching HTTP Caching
draft-ietf-httpbis-cache-07 draft-ietf-httpbis-cache-08
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.8. The changes in this draft are summarized in Appendix C.9.
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 September 8, 2020. This Internet-Draft will expire on November 27, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 44 skipping to change at page 2, line 44
than English. than English.
Table of Contents Table of Contents
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 . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Delta Seconds . . . . . . . . . . . . . . . . . . . . . . 6
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 Incomplete Responses . . . . . . . . . . . . . . 8 3.1. Storing Header and Trailer Fields . . . . . . . . . . . . 8
3.2. Storing Responses to Authenticated Requests . . . . . . . 9 3.2. Storing Incomplete Responses . . . . . . . . . . . . . . 9
3.3. Combining Partial Content . . . . . . . . . . . . . . . . 9 3.3. Storing Responses to Authenticated Requests . . . . . . . 9
3.4. Combining Partial Content . . . . . . . . . . . . . . . . 10
4. Constructing Responses from Caches . . . . . . . . . . . . . 10 4. Constructing Responses from Caches . . . . . . . . . . . . . 10
4.1. Calculating Cache Keys with Vary . . . . . . . . . . . . 11 4.1. Calculating Cache Keys with Vary . . . . . . . . . . . . 11
4.2. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2.1. Calculating Freshness Lifetime . . . . . . . . . . . 13 4.2.1. Calculating Freshness Lifetime . . . . . . . . . . . 14
4.2.2. Calculating Heuristic Freshness . . . . . . . . . . . 14 4.2.2. Calculating Heuristic Freshness . . . . . . . . . . . 14
4.2.3. Calculating Age . . . . . . . . . . . . . . . . . . . 15 4.2.3. Calculating Age . . . . . . . . . . . . . . . . . . . 15
4.2.4. Serving Stale Responses . . . . . . . . . . . . . . . 16 4.2.4. Serving Stale Responses . . . . . . . . . . . . . . . 16
4.3. Validation . . . . . . . . . . . . . . . . . . . . . . . 16 4.3. Validation . . . . . . . . . . . . . . . . . . . . . . . 17
4.3.1. Sending a Validation Request . . . . . . . . . . . . 17 4.3.1. Sending a Validation Request . . . . . . . . . . . . 17
4.3.2. Handling a Received Validation Request . . . . . . . 17 4.3.2. Handling a Received Validation Request . . . . . . . 18
4.3.3. Handling a Validation Response . . . . . . . . . . . 19 4.3.3. Handling a Validation Response . . . . . . . . . . . 19
4.3.4. Freshening Stored Responses upon Validation . . . . . 19 4.3.4. Freshening Stored Responses upon Validation . . . . . 20
4.3.5. Freshening Responses with HEAD . . . . . . . . . . . 20 4.3.5. Freshening Responses with HEAD . . . . . . . . . . . 20
4.4. Invalidation . . . . . . . . . . . . . . . . . . . . . . 21 4.4. Invalidation . . . . . . . . . . . . . . . . . . . . . . 21
5. Field Definitions . . . . . . . . . . . . . . . . . . . . . . 21 5. Field Definitions . . . . . . . . . . . . . . . . . . . . . . 22
5.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 5.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 22 5.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 23
5.2.1. Request Cache-Control Directives . . . . . . . . . . 23 5.2.1. Request Cache-Control Directives . . . . . . . . . . 24
5.2.1.1. max-age . . . . . . . . . . . . . . . . . . . . . 23 5.2.1.1. max-age . . . . . . . . . . . . . . . . . . . . . 24
5.2.1.2. max-stale . . . . . . . . . . . . . . . . . . . . 24 5.2.1.2. max-stale . . . . . . . . . . . . . . . . . . . . 24
5.2.1.3. min-fresh . . . . . . . . . . . . . . . . . . . . 24 5.2.1.3. min-fresh . . . . . . . . . . . . . . . . . . . . 25
5.2.1.4. no-cache . . . . . . . . . . . . . . . . . . . . 24 5.2.1.4. no-cache . . . . . . . . . . . . . . . . . . . . 25
5.2.1.5. no-store . . . . . . . . . . . . . . . . . . . . 25 5.2.1.5. no-store . . . . . . . . . . . . . . . . . . . . 25
5.2.1.6. no-transform . . . . . . . . . . . . . . . . . . 25 5.2.1.6. no-transform . . . . . . . . . . . . . . . . . . 26
5.2.1.7. only-if-cached . . . . . . . . . . . . . . . . . 25 5.2.1.7. only-if-cached . . . . . . . . . . . . . . . . . 26
5.2.2. Response Cache-Control Directives . . . . . . . . . . 25 5.2.2. Response Cache-Control Directives . . . . . . . . . . 26
5.2.2.1. must-revalidate . . . . . . . . . . . . . . . . . 25 5.2.2.1. must-revalidate . . . . . . . . . . . . . . . . . 26
5.2.2.2. must-understand . . . . . . . . . . . . . . . . . 26 5.2.2.2. must-understand . . . . . . . . . . . . . . . . . 27
5.2.2.3. no-cache . . . . . . . . . . . . . . . . . . . . 26 5.2.2.3. no-cache . . . . . . . . . . . . . . . . . . . . 27
5.2.2.4. no-store . . . . . . . . . . . . . . . . . . . . 27 5.2.2.4. no-store . . . . . . . . . . . . . . . . . . . . 28
5.2.2.5. no-transform . . . . . . . . . . . . . . . . . . 27 5.2.2.5. no-transform . . . . . . . . . . . . . . . . . . 28
5.2.2.6. public . . . . . . . . . . . . . . . . . . . . . 27 5.2.2.6. public . . . . . . . . . . . . . . . . . . . . . 28
5.2.2.7. private . . . . . . . . . . . . . . . . . . . . . 28 5.2.2.7. private . . . . . . . . . . . . . . . . . . . . . 28
5.2.2.8. proxy-revalidate . . . . . . . . . . . . . . . . 28 5.2.2.8. proxy-revalidate . . . . . . . . . . . . . . . . 29
5.2.2.9. max-age . . . . . . . . . . . . . . . . . . . . . 29 5.2.2.9. max-age . . . . . . . . . . . . . . . . . . . . . 29
5.2.2.10. s-maxage . . . . . . . . . . . . . . . . . . . . 29 5.2.2.10. s-maxage . . . . . . . . . . . . . . . . . . . . 30
5.2.3. Cache Control Extensions . . . . . . . . . . . . . . 29 5.2.3. Cache Control Extensions . . . . . . . . . . . . . . 30
5.2.4. Cache Directive Registry . . . . . . . . . . . . . . 30 5.2.4. Cache Directive Registry . . . . . . . . . . . . . . 31
5.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 31 5.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . 32 5.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.5. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 32 5.5. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 33
6. Relationship to Applications . . . . . . . . . . . . . . . . 32 6. Relationship to Applications . . . . . . . . . . . . . . . . 33
7. Security Considerations . . . . . . . . . . . . . . . . . . . 33 7. Security Considerations . . . . . . . . . . . . . . . . . . . 33
7.1. Cache Poisoning . . . . . . . . . . . . . . . . . . . . . 33 7.1. Cache Poisoning . . . . . . . . . . . . . . . . . . . . . 34
7.2. Timing Attacks . . . . . . . . . . . . . . . . . . . . . 33 7.2. Timing Attacks . . . . . . . . . . . . . . . . . . . . . 34
7.3. Caching of Sensitive Information . . . . . . . . . . . . 34 7.3. Caching of Sensitive Information . . . . . . . . . . . . 34
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
8.1. Field Registration . . . . . . . . . . . . . . . . . . . 34 8.1. Field Registration . . . . . . . . . . . . . . . . . . . 35
8.2. Cache Directive Registration . . . . . . . . . . . . . . 34 8.2. Cache Directive Registration . . . . . . . . . . . . . . 35
8.3. Warn Code Registry . . . . . . . . . . . . . . . . . . . 34 8.3. Warn Code Registry . . . . . . . . . . . . . . . . . . . 35
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
9.1. Normative References . . . . . . . . . . . . . . . . . . 34 9.1. Normative References . . . . . . . . . . . . . . . . . . 35
9.2. Informative References . . . . . . . . . . . . . . . . . 35 9.2. Informative References . . . . . . . . . . . . . . . . . 36
Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 37 Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 37
Appendix B. Changes from RFC 7234 . . . . . . . . . . . . . . . 37 Appendix B. Changes from RFC 7234 . . . . . . . . . . . . . . . 37
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 38 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 38
C.1. Between RFC7234 and draft 00 . . . . . . . . . . . . . . 38 C.1. Between RFC7234 and draft 00 . . . . . . . . . . . . . . 38
C.2. Since draft-ietf-httpbis-cache-00 . . . . . . . . . . . . 38 C.2. Since draft-ietf-httpbis-cache-00 . . . . . . . . . . . . 38
C.3. Since draft-ietf-httpbis-cache-01 . . . . . . . . . . . . 38 C.3. Since draft-ietf-httpbis-cache-01 . . . . . . . . . . . . 38
C.4. Since draft-ietf-httpbis-cache-02 . . . . . . . . . . . . 38 C.4. Since draft-ietf-httpbis-cache-02 . . . . . . . . . . . . 38
C.5. Since draft-ietf-httpbis-cache-03 . . . . . . . . . . . . 39 C.5. Since draft-ietf-httpbis-cache-03 . . . . . . . . . . . . 39
C.6. Since draft-ietf-httpbis-cache-04 . . . . . . . . . . . . 39 C.6. Since draft-ietf-httpbis-cache-04 . . . . . . . . . . . . 39
C.7. Since draft-ietf-httpbis-cache-05 . . . . . . . . . . . . 39 C.7. Since draft-ietf-httpbis-cache-05 . . . . . . . . . . . . 39
C.8. Since draft-ietf-httpbis-cache-06 . . . . . . . . . . . . 40 C.8. Since draft-ietf-httpbis-cache-06 . . . . . . . . . . . . 40
C.9. Since draft-ietf-httpbis-cache-07 . . . . . . . . . . . . 40
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 42 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
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. HTTP is defined by a series of hypertext information systems. HTTP is defined by a series of
documents that collectively form the HTTP/1.1 specification: documents that collectively form the HTTP/1.1 specification:
skipping to change at page 7, line 17 skipping to change at page 7, line 17
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, as per Section 4.1. header fields into the cache key as well, as per Section 4.1.
Furthermore, caches might incorporate additional material into the Furthermore, caches might incorporate additional material into the
cache key. For example, user agent caches might include the cache key. For example, user agent caches might include the
referring site's identity, thereby "double keying" the cache to avoid referring site's identity, thereby "double keying" the cache to avoid
some privacy risks (see Section 7.2). some privacy risks (see Section 7.2).
Most commonly, caches store the successful result of a retrieval Most commonly, caches store the successful result of a retrieval
request: i.e., a 200 (OK) response to a GET request, which contains a request: i.e., a 200 (OK) response to a GET request, which contains a
representation of the resource identified by the request target representation of the target resource (Section 7.3.1 of [Semantics]).
(Section 7.3.1 of [Semantics]). However, it is also possible to However, it is also possible to store redirects, negative results
store redirects, negative results (e.g., 404 (Not Found)), incomplete (e.g., 404 (Not Found)), incomplete results (e.g., 206 (Partial
results (e.g., 206 (Partial Content)), and responses to methods other Content)), and responses to methods other than GET if the method's
than GET if the method's definition allows such caching and defines definition allows such caching and defines something suitable for use
something suitable for use as a cache key. as a cache key.
A cache is disconnected when it cannot contact the origin server or A cache is disconnected when it cannot contact the origin server or
otherwise find a forward path for a given request. A disconnected otherwise find a forward path for a given request. A disconnected
cache can serve stale responses in some circumstances cache can serve stale responses in some circumstances
(Section 4.2.4). (Section 4.2.4).
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:
skipping to change at page 7, line 51 skipping to change at page 7, line 51
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); Section 5.2);
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 modified response to be stored by a shared not present or allows a modified response to be stored by a shared
cache; see Section 5.2.2.7); cache; 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 8.5.3 of [Semantics]) or a present in the request (see Section 8.5.3 of [Semantics]) or a
response directive is present that explicitly allows shared response directive is present that explicitly allows shared
caching (see Section 3.2); and, caching (see Section 3.3); 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.6);
* a private response directive, if the cache is not shared (see
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.9);
* 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,
skipping to change at page 8, line 34 skipping to change at page 8, line 37
In this context, a cache has "understood" a request method or a In this context, a cache has "understood" a request method or a
response status code if it recognizes it and implements all specified response status code if it recognizes it and implements all specified
caching-related behavior. caching-related behavior.
Note that, in normal operation, some caches will not store a response Note that, in normal operation, some caches will not store a response
that has neither a cache validator nor an explicit expiration time, that has neither a cache validator nor an explicit expiration time,
as such responses are not usually useful to store. However, caches as such responses are not usually useful to store. However, caches
are not prohibited from storing such responses. are not prohibited from storing such responses.
3.1. Storing Incomplete Responses 3.1. Storing Header and Trailer Fields
A response message is considered complete when all of the octets Caches MUST include all received header fields -- including
indicated by its framing are available. Note that, when no explicit unrecognised ones -- when storing a response; this assures that new
framing is provided, a response message that is ended by the HTTP header fields can be successfully deployed. However, the
connection's close is considered complete even though it might be following exceptions are made:
indistinguishable from an incomplete response (see [Messaging],
Section 6.3). A cache SHOULD consider a close-terminated response o The Connection header field and fields whose names are listed in
incomplete if the connection termination is detected to be an error. it are required by Section 13.1 of [Semantics] to be removed
A server that wishes to avoid premature termination resulting in an before forwarding the message. This MAY be implemented by doing
incorrect cached response SHOULD send the response with explicit so before storage.
framing.
o Likewise, some fields' semantics require them to be removed before
forwarding the message, and this MAY be implemented by doing so
before storage; see Section 13.1 of [Semantics] for some examples.
o Header fields that are specific to a client's proxy configuration
MUST NOT be stored, unless the cache incorporates the identity of
the proxy into the cache key. Effectively, this is limited to
Proxy-Authenticate Section 10.3.2 of [Semantics], Proxy-
Authentication-Info Section 10.3.4 of [Semantics], and Proxy-
Authorization Section 8.5.4 of [Semantics].
Caches MAY either store trailer fields separately from header fields,
or discard them. Caches MUST NOT combine trailer fields with header
fields.
3.2. Storing Incomplete Responses
If the request method is GET, the response status code is 200 (OK), If the request method is GET, the response status code is 200 (OK),
and the entire response header section has been received, a cache MAY and the entire response header section has been received, a cache MAY
store an incomplete response message body if the stored response is store a response body that is not complete (Section 2.1 of
recorded as incomplete. Likewise, a 206 (Partial Content) response [Semantics]) if the stored response is recorded as being incomplete.
MAY be stored as if it were an incomplete 200 (OK) response. Likewise, a 206 (Partial Content) response MAY be stored as if it
However, a cache MUST NOT store incomplete or partial-content were an incomplete 200 (OK) response. However, a cache MUST NOT
responses if it does not support the Range and Content-Range header store incomplete or partial-content responses if it does not support
fields or if it does not understand the range units used in those the Range and Content-Range header fields or if it does not
fields. understand the range units used in those fields.
A cache MAY complete a stored incomplete response by making a A cache MAY complete a stored incomplete response by making a
subsequent range request (Section 8.3 of [Semantics]) and combining subsequent range request (Section 8.3 of [Semantics]) and combining
the successful response with the stored response, as defined in the successful response with the stored response, as defined in
Section 3.3. A cache MUST NOT use an incomplete response to answer Section 3.4. A cache MUST NOT use an incomplete response to answer
requests unless the response has been made complete or the request is requests unless the response has been made complete or the request is
partial and specifies a range that is wholly within the incomplete partial and specifies a range that is wholly within the incomplete
response. A cache MUST NOT send a partial response to a client response. A cache MUST NOT send a partial response to a client
without explicitly marking it as such using the 206 (Partial Content) without explicitly marking it as such using the 206 (Partial Content)
status code. status code.
3.2. Storing Responses to Authenticated Requests 3.3. 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 8.5.3 of [Semantics]) to satisfy Authorization header field (Section 8.5.3 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.1), public (Section 5.2.2.6),
and s-maxage (Section 5.2.2.10). and s-maxage (Section 5.2.2.10).
3.3. Combining Partial Content 3.4. Combining Partial Content
A response might transfer only a partial representation if the A response might transfer only a partial representation if the
connection closed prematurely or if the request used one or more connection closed prematurely or if the request used one or more
Range specifiers (Section 8.3 of [Semantics]). After several such Range specifiers (Section 8.3 of [Semantics]). After several such
transfers, a cache might have received several ranges of the same transfers, a cache might have received several ranges of the same
representation. A cache MAY combine these ranges into a single representation. A cache MAY combine these ranges into a single
stored response, and reuse that response to satisfy later requests, stored response, and reuse that response to satisfy later requests,
if they all share the same strong validator and the cache complies if they all share the same strong validator and the cache complies
with the client requirements in Section 9.3.7.3 of [Semantics]. with the client requirements in Section 9.3.7.3 of [Semantics].
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 use the header fields provided in the new response, aside cache MUST use the header fields provided in the new response, aside
from Content-Range, to replace all instances of the corresponding from 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:
o The presented effective request URI (Section 5.5 of [Semantics]) o The presented target URI (Section 5.1 of [Semantics]) and that of
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.3), unless it is successfully validated
(Section 4.3), and (Section 4.3), and
skipping to change at page 17, line 10 skipping to change at page 17, line 28
stored response to use, updating the stored metadata in the process, stored response to use, updating the stored metadata in the process,
or to replace the stored response(s) with a new response. This or to replace the stored response(s) with a new response. This
process is known as "validating" or "revalidating" the stored process is known as "validating" or "revalidating" the stored
response. response.
4.3.1. Sending a Validation Request 4.3.1. Sending a Validation Request
When generating a conditional request for validation, a cache starts When generating a conditional request for validation, a cache starts
with either a request it is attempting to satisfy, or -- if it is with either a request it is attempting to satisfy, or -- if it is
initiating the request independently -- it synthesises a request initiating the request independently -- it synthesises a request
using a stored response by copying the method, request-target, and using a stored response by copying the method, target URI, and
request header fields identified by the Vary header field request header fields identified by the Vary header field
Section 4.1. Section 4.1.
It then updates that request with one or more precondition header It then updates that request with one or more precondition header
fields. These contain validator metadata sourced from stored fields. These contain validator metadata sourced from stored
response(s) that have the same cache key. response(s) that have the same cache key.
The precondition header fields are then compared by recipients to The precondition header fields are then compared by recipients to
determine whether any stored response is equivalent to a current determine whether any stored response is equivalent to a current
representation of the resource. representation of the resource.
skipping to change at page 20, line 17 skipping to change at page 20, line 38
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
identified for update. identified for update.
For each stored response identified for update, the cache MUST use For each stored response identified for update, the cache MUST use
the header fields provided in the 304 (Not Modified) response to the header fields provided in the 304 (Not Modified) response to
replace all instances of the corresponding header fields in the replace all instances of the corresponding header fields in the
stored response. stored response, with the following exceptions:
o The exceptions to header field storage in Section 3.1 also apply
to header field updates.
o Caches MUST NOT update the following header fields: Content-
Encoding, Content-Length, Content-MD5 (Section 14.15 of
[RFC2616]), Content-Range, ETag.
4.3.5. Freshening Responses with HEAD 4.3.5. Freshening Responses with 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
cached GET response if the more efficient conditional GET request cached GET response if the more efficient conditional GET request
mechanism is not available (due to no validators being present in the mechanism is not available (due to no validators being present in the
stored response) or if transmission of the representation body is not stored response) or if transmission of the representation body is not
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 target URI and
and receives a 200 (OK) response, the cache SHOULD update or receives a 200 (OK) response, the cache SHOULD update or invalidate
invalidate each of its stored GET responses that could have been each of its stored GET responses that could have been selected for
selected for that request (see Section 4.1). that request (see Section 4.1).
For each of the stored responses that could have been selected, if For each of the stored responses that could have been selected, if
the stored response and HEAD response have matching values for any the stored response and HEAD response have matching values for any
received validator fields (ETag and Last-Modified) and, if the HEAD received validator fields (ETag and Last-Modified) and, if the HEAD
response has a Content-Length header field, the value of Content- response has a Content-Length header field, the value of Content-
Length matches that of the stored response, the cache SHOULD update Length matches that of the stored response, the cache SHOULD update
the stored response as described below; otherwise, the cache SHOULD the stored response as described below; otherwise, the cache SHOULD
consider the stored response to be stale. consider the stored response to be stale.
If a cache updates a stored response with the metadata provided in a If a cache updates a stored response with the metadata provided in a
HEAD response, the cache MUST use the header fields provided in the HEAD response, the cache MUST use the header fields provided in the
HEAD response to replace all instances of the corresponding header HEAD response to replace all instances of the corresponding header
fields in the stored response and append new header fields to the fields in the stored response (subject to the exceptions in
stored response's header section unless otherwise restricted by the Section 4.3.4) and append new header fields to the stored response's
Cache-Control header field. header section unless otherwise restricted by the Cache-Control
header field.
4.4. Invalidation 4.4. Invalidation
Because unsafe request methods (Section 7.2.1 of [Semantics]) such as Because unsafe request methods (Section 7.2.1 of [Semantics]) such as
PUT, POST or DELETE have the potential for changing state on the PUT, POST or DELETE have the potential for changing state on the
origin server, intervening caches can use them to keep their contents origin server, intervening caches are required to invalidate stored
up to date. responses to keep their contents up to date. Invalidate means that
the cache will either remove all stored responses whose target URI
matches the given URI, or will mark them as "invalid" and in need of
a mandatory validation before they can be sent in response to a
subsequent request.
A cache MUST invalidate the effective Request URI (Section 5.5 of Note that this does not guarantee that all appropriate responses are
[Semantics]) as well as the URI(s) in the Location and Content- invalidated globally; a state-changing request would only invalidate
Location response header fields (if present) when a non-error status responses in the caches that it travels through.
code is received in response to an unsafe request method.
A cache MUST invalidate the target URI (Section 5.1 of [Semantics])
as well as the URI(s) in the Location and Content-Location response
header fields (if present) when a non-error status code is received
in response to an unsafe request method.
However, a cache MUST NOT invalidate a URI from a Location or However, a cache MUST NOT invalidate a URI from a Location or
Content-Location response header field if the host part of that URI Content-Location response header field if the host part of that URI
differs from the host part in the effective request URI (Section 5.5 differs from the host part in the target URI (Section 5.1 of
of [Semantics]). This helps prevent denial-of-service attacks. [Semantics]). This helps prevent denial-of-service attacks.
A cache MUST invalidate the effective request URI (Section 5.5 of A cache MUST invalidate the target URI (Section 5.1 of [Semantics])
[Semantics]) when it receives a non-error response to a request with when it receives a non-error response to a request with a method
a method whose safety is unknown. whose safety is unknown.
Here, a "non-error response" is one with a 2xx (Successful) or 3xx Here, a "non-error response" is one with a 2xx (Successful) or 3xx
(Redirection) status code. "Invalidate" means that the cache will (Redirection) status code.
either remove all stored responses related to the effective request
URI or will mark these as "invalid" and in need of a mandatory
validation before they can be sent in response to a subsequent
request.
Note that this does not guarantee that all appropriate responses are
invalidated. For example, a state-changing request might invalidate
responses in the caches it travels through, but relevant responses
still might be stored in other caches that it has not.
5. Field Definitions 5. Field Definitions
This section defines the syntax and semantics of HTTP fields related This section defines the syntax and semantics of HTTP fields related
to caching. to caching.
+---------------+-----------+--------------+ +---------------+-----------+--------------+
| Field Name | Status | Reference | | Field Name | Status | Reference |
+---------------+-----------+--------------+ +---------------+-----------+--------------+
| Age | standard | Section 5.1 | | Age | standard | Section 5.1 |
skipping to change at page 26, line 18 skipping to change at page 26, line 50
cache is disconnected, the cache MUST generate a 504 (Gateway cache is disconnected, the cache MUST generate a 504 (Gateway
Timeout) response rather than reuse the stale response. Timeout) response rather than reuse the stale response.
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 on the representation could result if failure to validate a request on the representation could result
in incorrect operation, such as a silently unexecuted financial in incorrect operation, such as a silently unexecuted financial
transaction. 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,
subject to the above requirement on revalidation (Section 3.2). subject to the above requirement on revalidation (Section 3.3).
5.2.2.2. must-understand 5.2.2.2. 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. A cache MUST NOT store a response for that response's status code. A cache MUST NOT store a response
containing the must-understand directive if the cache does not containing the must-understand directive if the cache does not
understand the response status code. understand the response status code.
5.2.2.3. no-cache 5.2.2.3. no-cache
skipping to change at page 27, line 45 skipping to change at page 28, line 32
5.2.2.5. no-transform 5.2.2.5. 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
payload, as defined in Section 5.7.2 of [Semantics]. payload, as defined in Section 5.7.2 of [Semantics].
5.2.2.6. public 5.2.2.6. public
The "public" response directive indicates that a cache MAY store the The "public" response directive indicates that a cache MAY store the
response even if it would otherwise be prohibited, subject to the response even if it would otherwise be prohibited, subject to the
constraints of any other response directives present. In other constraints defined in Section 3. In other words, public explicitly
words, public explicitly marks the response as cacheable. For marks the response as cacheable. For example, public permits a
example, public permits a shared cache to reuse a response to a shared cache to reuse a response to a request containing an
request containing an Authorization header field (Section 3.2). Authorization header field (Section 3.3).
If no explicit freshness information is provided, the response is is Note that it is not necessary to add the public directive to a
heuristically cacheable (Section 4.2.2). response that is already cacheable according to Section 3.
If no explicit freshness information is provided on a response with
the public directive, 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 to any other cache directives present, even if the response, subject the constraints defined in Section 3, even if the
response would not otherwise be heuristically cacheable by a private response would not otherwise be heuristically cacheable by a private
cache. cache.
If a qualified private response directive is present, with an If a qualified private response directive is present, with an
argument that lists one or more field names, then only the listed argument that lists one or more field names, then only the listed
fields are limited to a single user: a shared cache MUST NOT store fields are limited to a single user: a shared cache MUST NOT store
the listed fields if they are present in the original response, but the listed fields if they are present in the original response, but
MAY store the remainder of the response message without those fields. MAY store the remainder of the response message without those fields,
subject the constraints defined in Section 3.
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: This usage of the word "private" only controls where the Note: This usage of the word "private" only controls where the
response can be stored; it cannot ensure the privacy of the message response can be stored; it cannot ensure the privacy of the message
skipping to change at page 29, line 37 skipping to change at page 30, line 27
specified by either the max-age directive or the Expires header specified by either the max-age directive or the Expires header
field. field.
The s-maxage directive incorporates the proxy-revalidate The s-maxage directive incorporates the proxy-revalidate
(Section 5.2.2.8) response directive's semantics for a shared cache. (Section 5.2.2.8) response directive's semantics for a shared cache.
A shared cache MUST NOT reuse a stale response with s-maxage to A shared cache MUST NOT reuse a stale response with s-maxage 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. This directive also permits a the origin, as defined by Section 4.3. This directive also permits a
shared cache to reuse a response to a request containing an shared cache to reuse a response to a request containing an
Authorization header field, subject to the above requirements on Authorization header field, subject to the above requirements on
maximum age and revalidation (Section 3.2). maximum age and revalidation (Section 3.3).
This directive uses the token form of the argument syntax: e.g., This directive uses the token form of the argument syntax: e.g.,
's-maxage=10' not 's-maxage="10"'. A sender MUST NOT generate the 's-maxage=10' not 's-maxage="10"'. A sender MUST NOT generate the
quoted-string form. quoted-string form.
5.2.3. Cache Control Extensions 5.2.3. Cache Control Extensions
The Cache-Control header field can be extended through the use of one The Cache-Control header field can be extended through the use of one
or more cache-extension tokens, each with an optional value. A cache or more cache-extension tokens, each with an optional value. A cache
MUST ignore unrecognized cache directives. MUST ignore unrecognized cache directives.
skipping to change at page 34, line 48 skipping to change at page 35, line 30
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 Messaging", draft-ietf-httpbis-messaging-07 Ed., "HTTP/1.1 Messaging", draft-ietf-httpbis-messaging-08
(work in progress), March 2020. (work in progress), May 2020.
[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>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
skipping to change at page 35, line 30 skipping to change at page 36, line 11
[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
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", draft-ietf-httpbis-semantics-07 Ed., "HTTP Semantics", draft-ietf-httpbis-semantics-08
(work in progress), March 2020. (work in progress), May 2020.
[USASCII] American National Standards Institute, "Coded Character [USASCII] American National Standards Institute, "Coded Character
Set -- 7-bit American Standard Code for Information Set -- 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986. Interchange", ANSI X3.4, 1986.
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,
skipping to change at page 37, line 49 skipping to change at page 37, line 49
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.2)
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, and in practice were 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.
C.1. Between RFC7234 and draft 00 C.1. Between RFC7234 and draft 00
The changes were purely editorial: The changes were purely editorial:
skipping to change at page 39, line 17 skipping to change at page 39, line 17
o In Section 4.3.1, clarify the source of validators in conditional o In Section 4.3.1, clarify the source of validators in conditional
requests (<https://github.com/httpwg/http-core/issues/110>) requests (<https://github.com/httpwg/http-core/issues/110>)
o Revise Section 6 to apply to more than just History Lists o Revise Section 6 to apply to more than just History Lists
(<https://github.com/httpwg/http-core/issues/126>) (<https://github.com/httpwg/http-core/issues/126>)
o In Section 5.5, deprecated "Warning" header field o In Section 5.5, deprecated "Warning" header field
(<https://github.com/httpwg/http-core/issues/139>) (<https://github.com/httpwg/http-core/issues/139>)
o In Section 3.2, remove a spurious note o In Section 3.3, remove a spurious note
(<https://github.com/httpwg/http-core/issues/141>) (<https://github.com/httpwg/http-core/issues/141>)
C.5. Since draft-ietf-httpbis-cache-03 C.5. Since draft-ietf-httpbis-cache-03
o In Section 2, define what a disconnected cache is o In Section 2, define what a disconnected cache is
(<https://github.com/httpwg/http-core/issues/5>) (<https://github.com/httpwg/http-core/issues/5>)
o In Section 4, clarify language around how to select a response o In Section 4, clarify language around how to select a response
when more than one matches (<https://github.com/httpwg/http-core/ when more than one matches (<https://github.com/httpwg/http-core/
issues/23>) issues/23>)
o in Section 4.2.4, mention stale-while-revalidate and stale-if- o in Section 4.2.4, mention stale-while-revalidate and stale-if-
error (<https://github.com/httpwg/http-core/issues/122>) error (<https://github.com/httpwg/http-core/issues/122>)
o Remove requirements around cache request directives o Remove requirements around cache request directives
(<https://github.com/httpwg/http-core/issues/129>) (<https://github.com/httpwg/http-core/issues/129>)
o Deprecate Pragma (<https://github.com/httpwg/http-core/ o Deprecate Pragma (<https://github.com/httpwg/http-core/
issues/140>) issues/140>)
o In Section 3.2 and Section 5.2.2, note effect of some directives o In Section 3.3 and Section 5.2.2, note effect of some directives
on authenticated requests (<https://github.com/httpwg/http-core/ on authenticated requests (<https://github.com/httpwg/http-core/
issues/161>) issues/161>)
C.6. Since draft-ietf-httpbis-cache-04 C.6. Since draft-ietf-httpbis-cache-04
o In Section 5.2, remove the registrations for stale-if-error and o In Section 5.2, remove the registrations for stale-if-error and
stale-while-revalidate which happened in RFC 7234 stale-while-revalidate which happened in RFC 7234
(<https://github.com/httpwg/http-core/issues/207>) (<https://github.com/httpwg/http-core/issues/207>)
C.7. Since draft-ietf-httpbis-cache-05 C.7. Since draft-ietf-httpbis-cache-05
o In Section 3.1, clarify how weakly framed content is considered o In Section 3.2, clarify how weakly framed content is considered
for purposes of completeness (<https://github.com/httpwg/http- for purposes of completeness (<https://github.com/httpwg/http-
core/issues/25>) core/issues/25>)
o Throughout, describe Vary and cache key operations more clearly o Throughout, describe Vary and cache key operations more clearly
(<https://github.com/httpwg/http-core/issues/28>) (<https://github.com/httpwg/http-core/issues/28>)
o In Section 3, remove concept of "cacheable methods" in favor of o In Section 3, remove concept of "cacheable methods" in favor of
prose (<https://github.com/httpwg/http-core/issues/54>, prose (<https://github.com/httpwg/http-core/issues/54>,
<https://www.rfc-editor.org/errata/eid5300>) <https://www.rfc-editor.org/errata/eid5300>)
skipping to change at page 41, line 5 skipping to change at page 40, line 46
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
o Throughout, replace "effective request URI", "request-target" and
similar with "target URI" (<https://github.com/httpwg/http-core/
issues/259>)
o In Section 5.2.2.6 and Section 5.2.2.7, make it clear that these
directives do not ignore other requirements for caching
(<https://github.com/httpwg/http-core/issues/320>)
o In Section 3.2, move definition of "complete" into semantics
(<https://github.com/httpwg/http-core/issues/334>)
Index Index
A A
Age header field 22 Age header field 22
age 12 age 12
C C
Cache-Control header field 22 Cache-Control header field 23
cache 4 cache 4
cache key 6 cache key 6
E E
Expires header field 31 Expires header field 31
explicit expiration time 12 explicit expiration time 12
F F
Fields Fields
Age 22 Age 22
Cache-Control 22 Cache-Control 23
Expires 31 Expires 31
Pragma 32 Pragma 32
Warning 32 Warning 33
fresh 12 fresh 12
freshness lifetime 12 freshness lifetime 12
G G
Grammar Grammar
Age 22 Age 22
ALPHA 5 ALPHA 5
Cache-Control 23 Cache-Control 23
cache-directive 23 cache-directive 23
CR 5 CR 5
CRLF 5 CRLF 5
CTL 5 CTL 5
delta-seconds 6 delta-seconds 6
DIGIT 5 DIGIT 5
DQUOTE 5 DQUOTE 5
Expires 31 Expires 32
HEXDIG 5 HEXDIG 5
HTAB 5 HTAB 5
LF 5 LF 5
OCTET 5 OCTET 5
SP 5 SP 5
VCHAR 5 VCHAR 5
H H
Header Fields Header Fields
Age 22 Age 22
Cache-Control 22 Cache-Control 23
Expires 31 Expires 31
Pragma 32 Pragma 32
Warning 32 Warning 33
heuristic expiration time 12 heuristic expiration time 12
heuristically cacheable 14 heuristically cacheable 14
M M
max-age (cache directive) 23, 29 max-age (cache directive) 24, 29
max-stale (cache directive) 24 max-stale (cache directive) 24
min-fresh (cache directive) 24 min-fresh (cache directive) 25
must-revalidate (cache directive) 25 must-revalidate (cache directive) 26
must-understand (cache directive) 26 must-understand (cache directive) 27
N N
no-cache (cache directive) 24, 26 no-cache (cache directive) 25, 27
no-store (cache directive) 25, 27 no-store (cache directive) 25, 28
no-transform (cache directive) 25, 27 no-transform (cache directive) 26, 28
O O
only-if-cached (cache directive) 25 only-if-cached (cache directive) 26
P P
Pragma header field 32 Pragma header field 32
private (cache directive) 28 private (cache directive) 28
private cache 4 private cache 4
proxy-revalidate (cache directive) 28 proxy-revalidate (cache directive) 29
public (cache directive) 27 public (cache directive) 28
S S
s-maxage (cache directive) 29 s-maxage (cache directive) 30
shared cache 4 shared cache 4
stale 12 stale 12
strong validator 19 strong validator 20
V V
validator 17 validator 17
W W
Warning header field 32 Warning header field 33
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
 End of changes. 68 change blocks. 
141 lines changed or deleted 185 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/