draft-ietf-httpbis-cache-09.txt   draft-ietf-httpbis-cache-10.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: January 12, 2021 J. Reschke, Ed. Expires: January 13, 2021 J. F. Reschke, Ed.
greenbytes greenbytes
July 11, 2020 July 12, 2020
HTTP Caching HTTP Caching
draft-ietf-httpbis-cache-09 draft-ietf-httpbis-cache-10
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.10. The changes in this draft are summarized in Appendix C.11.
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 January 12, 2021. This Internet-Draft will expire on January 13, 2021.
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/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Simplified BSD License.
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
skipping to change at page 2, line 46 skipping to change at page 2, line 48
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 Header and Trailer Fields . . . . . . . . . . . . 8 3.1. Storing Header and Trailer Fields . . . . . . . . . . . . 8
3.2. Storing Incomplete Responses . . . . . . . . . . . . . . 9 3.2. Storing Incomplete Responses . . . . . . . . . . . . . . 9
3.3. Storing Responses to Authenticated Requests . . . . . . . 9 3.3. Storing Responses to Authenticated Requests . . . . . . . 10
3.4. Combining Partial Content . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . . . . . . . 17 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 . . . . . . . 18 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 . . . . . 20 4.3.4. Freshening Stored Responses upon Validation . . . . . 20
4.3.5. Freshening Responses with HEAD . . . . . . . . . . . 20 4.3.5. Freshening Responses with HEAD . . . . . . . . . . . 21
4.4. Invalidation . . . . . . . . . . . . . . . . . . . . . . 21 4.4. Invalidation . . . . . . . . . . . . . . . . . . . . . . 21
5. Field Definitions . . . . . . . . . . . . . . . . . . . . . . 22 5. Field Definitions . . . . . . . . . . . . . . . . . . . . . . 22
5.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 5.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 23 5.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 23
5.2.1. Request Cache-Control Directives . . . . . . . . . . 24 5.2.1. Request Cache-Control Directives . . . . . . . . . . 24
5.2.1.1. max-age . . . . . . . . . . . . . . . . . . . . . 24 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 . . . . . . . . . . . . . . . . . . . . 25 5.2.1.3. min-fresh . . . . . . . . . . . . . . . . . . . . 25
5.2.1.4. no-cache . . . . . . . . . . . . . . . . . . . . 25 5.2.1.4. no-cache . . . . . . . . . . . . . . . . . . . . 25
5.2.1.5. no-store . . . . . . . . . . . . . . . . . . . . 25 5.2.1.5. no-store . . . . . . . . . . . . . . . . . . . . 25
skipping to change at page 3, line 38 skipping to change at page 3, line 39
5.2.2.3. no-cache . . . . . . . . . . . . . . . . . . . . 27 5.2.2.3. no-cache . . . . . . . . . . . . . . . . . . . . 27
5.2.2.4. no-store . . . . . . . . . . . . . . . . . . . . 28 5.2.2.4. no-store . . . . . . . . . . . . . . . . . . . . 28
5.2.2.5. no-transform . . . . . . . . . . . . . . . . . . 28 5.2.2.5. no-transform . . . . . . . . . . . . . . . . . . 28
5.2.2.6. public . . . . . . . . . . . . . . . . . . . . . 28 5.2.2.6. public . . . . . . . . . . . . . . . . . . . . . 28
5.2.2.7. private . . . . . . . . . . . . . . . . . . . . . 28 5.2.2.7. private . . . . . . . . . . . . . . . . . . . . . 28
5.2.2.8. proxy-revalidate . . . . . . . . . . . . . . . . 29 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 . . . . . . . . . . . . . . . . . . . . 30 5.2.2.10. s-maxage . . . . . . . . . . . . . . . . . . . . 30
5.2.3. Cache Control Extensions . . . . . . . . . . . . . . 30 5.2.3. Cache Control Extensions . . . . . . . . . . . . . . 30
5.2.4. Cache Directive Registry . . . . . . . . . . . . . . 31 5.2.4. Cache Directive Registry . . . . . . . . . . . . . . 31
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 . . . . . . . . . . . . . . . . 33 6. Relationship to Applications . . . . . . . . . . . . . . . . 33
7. Security Considerations . . . . . . . . . . . . . . . . . . . 33 7. Security Considerations . . . . . . . . . . . . . . . . . . . 34
7.1. Cache Poisoning . . . . . . . . . . . . . . . . . . . . . 34 7.1. Cache Poisoning . . . . . . . . . . . . . . . . . . . . . 34
7.2. Timing Attacks . . . . . . . . . . . . . . . . . . . . . 34 7.2. Timing Attacks . . . . . . . . . . . . . . . . . . . . . 34
7.3. Caching of Sensitive Information . . . . . . . . . . . . 34 7.3. Caching of Sensitive Information . . . . . . . . . . . . 35
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
8.1. Field Registration . . . . . . . . . . . . . . . . . . . 35 8.1. Field Registration . . . . . . . . . . . . . . . . . . . 35
8.2. Cache Directive Registration . . . . . . . . . . . . . . 35 8.2. Cache Directive Registration . . . . . . . . . . . . . . 35
8.3. Warn Code Registry . . . . . . . . . . . . . . . . . . . 35 8.3. Warn Code Registry . . . . . . . . . . . . . . . . . . . 35
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
9.1. Normative References . . . . . . . . . . . . . . . . . . 35 9.1. Normative References . . . . . . . . . . . . . . . . . . 35
9.2. Informative References . . . . . . . . . . . . . . . . . 36 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 . . . . . . . . . . . . . . . 38
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 . . . . . . . . . . . . 39
C.3. Since draft-ietf-httpbis-cache-01 . . . . . . . . . . . . 38 C.3. Since draft-ietf-httpbis-cache-01 . . . . . . . . . . . . 39
C.4. Since draft-ietf-httpbis-cache-02 . . . . . . . . . . . . 38 C.4. Since draft-ietf-httpbis-cache-02 . . . . . . . . . . . . 39
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 . . . . . . . . . . . . 40
C.7. Since draft-ietf-httpbis-cache-05 . . . . . . . . . . . . 39 C.7. Since draft-ietf-httpbis-cache-05 . . . . . . . . . . . . 40
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 C.9. Since draft-ietf-httpbis-cache-07 . . . . . . . . . . . . 41
C.10. Since draft-ietf-httpbis-cache-08 . . . . . . . . . . . . 41 C.10. Since draft-ietf-httpbis-cache-08 . . . . . . . . . . . . 41
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 C.11. Since draft-ietf-httpbis-cache-09 . . . . . . . . . . . . 41
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 43 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
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:
o "HTTP Semantics" [Semantics] o "HTTP Semantics" [Semantics]
skipping to change at page 6, line 26 skipping to change at page 6, line 35
delta-seconds = 1*DIGIT delta-seconds = 1*DIGIT
A recipient parsing a delta-seconds value and converting it to binary A recipient parsing a delta-seconds value and converting it to binary
form ought to use an arithmetic type of at least 31 bits of non- form ought to use an arithmetic type of at least 31 bits of non-
negative integer range. If a cache receives a delta-seconds value negative integer range. If a cache receives a delta-seconds value
greater than the greatest integer it can represent, or if any of its greater than the greatest integer it can represent, or if any of its
subsequent calculations overflows, the cache MUST consider the value subsequent calculations overflows, the cache MUST consider the value
to be either 2147483648 (2^31) or the greatest positive integer it to be either 2147483648 (2^31) or the greatest positive integer it
can conveniently represent. can conveniently represent.
Note: The value 2147483648 is here for historical reasons, | *Note:* The value 2147483648 is here for historical reasons,
effectively represents infinity (over 68 years), and does not need | effectively represents infinity (over 68 years), and does not
to be stored in binary form; an implementation could produce it as | need to be stored in binary form; an implementation could
a canned string if any overflow occurs, even if the calculations | produce it as a canned string if any overflow occurs, even if
are performed with an arithmetic type incapable of directly | the calculations are performed with an arithmetic type
representing that number. What matters here is that an overflow | incapable of directly representing that number. What matters
be detected and not treated as a negative value in later | here is that an overflow be detected and not treated as a
calculations. | negative value in later calculations.
2. Overview of Cache Operation 2. Overview of Cache Operation
Proper cache operation preserves the semantics of HTTP transfers Proper cache operation preserves the semantics of HTTP transfers
([Semantics]) while reducing the transfer of information already held ([Semantics]) while reducing the transfer of information already held
in the cache. Although caching is an entirely OPTIONAL feature of in the cache. Although caching is an entirely OPTIONAL feature of
HTTP, it can be assumed that reusing a cached response is desirable HTTP, it can be assumed that reusing a cached response is desirable
and that such reuse is the default behavior when no requirement or and that such reuse is the default behavior when no requirement or
local configuration prevents it. Therefore, HTTP cache requirements local configuration prevents it. Therefore, HTTP cache requirements
are focused on preventing a cache from either storing a non-reusable are focused on preventing a cache from either storing a non-reusable
skipping to change at page 8, line 39 skipping to change at page 8, line 48
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 Header and Trailer Fields 3.1. Storing Header and Trailer Fields
Caches MUST include all received header fields -- including Caches MUST include all received header fields - including
unrecognised ones -- when storing a response; this assures that new unrecognised ones - when storing a response; this assures that new
HTTP header fields can be successfully deployed. However, the HTTP header fields can be successfully deployed. However, the
following exceptions are made: following exceptions are made:
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 9.1 of [Messaging] to be removed before it are required by Section 9.1 of [Messaging] to be removed before
forwarding the message. This MAY be implemented by doing so forwarding the message. This MAY be implemented by doing so
before storage. 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
skipping to change at page 15, line 15 skipping to change at page 15, line 18
(e.g., with a "public" response directive). (e.g., with a "public" response directive).
Note that in previous specifications heuristically cacheable response Note that in previous specifications heuristically cacheable response
status codes were called "cacheable by default." status codes were called "cacheable by default."
If the response has a Last-Modified header field (Section 11.2.2 of If the response has a Last-Modified header field (Section 11.2.2 of
[Semantics]), caches are encouraged to use a heuristic expiration [Semantics]), caches are encouraged to use a heuristic expiration
value that is no more than some fraction of the interval since that value that is no more than some fraction of the interval since that
time. A typical setting of this fraction might be 10%. time. A typical setting of this fraction might be 10%.
Note: Section 13.9 of [RFC2616] prohibited caches from calculating | *Note:* Section 13.9 of [RFC2616] prohibited caches from
heuristic freshness for URIs with query components (i.e., those | calculating heuristic freshness for URIs with query components
containing '?'). In practice, this has not been widely | (i.e., those containing '?'). In practice, this has not been
implemented. Therefore, origin servers are encouraged to send | widely implemented. Therefore, origin servers are encouraged
explicit directives (e.g., Cache-Control: no-cache) if they wish | to send explicit directives (e.g., Cache-Control: no-cache) if
to preclude caching. | they wish to preclude caching.
4.2.3. Calculating Age 4.2.3. Calculating Age
The Age header field is used to convey an estimated age of the The Age header field is used to convey an estimated age of the
response message when obtained from a cache. The Age field value is response message when obtained from a cache. The Age field value is
the cache's estimate of the number of seconds since the response was the cache's estimate of the number of seconds since the response was
generated or validated by the origin server. In essence, the Age generated or validated by the origin server. In essence, the Age
value is the sum of the time that the response has been resident in value is the sum of the time that the response has been resident in
each of the caches along the path from the origin server, plus the each of the caches along the path from the origin server, plus the
amount of time it has been in transit along network paths. amount of time it has been in transit along network paths.
skipping to change at page 17, line 26 skipping to change at page 17, line 32
request mechanism Section 9.2 of [Semantics] in the forwarded request request mechanism Section 9.2 of [Semantics] in the forwarded request
to give the next inbound server an opportunity to select a valid to give the next inbound server an opportunity to select a valid
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
using a stored response by copying the method, target URI, and a stored response by copying the method, target URI, and request
request header fields identified by the Vary header field 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.
One such validator is the timestamp given in a Last-Modified header One such validator is the timestamp given in a Last-Modified header
skipping to change at page 22, line 19 skipping to change at page 22, line 27
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. (Redirection) status code.
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 | | Cache-Control | standard | Section 5.2 |
| Cache-Control | standard | Section 5.2 | | Expires | standard | Section 5.3 |
| Expires | standard | Section 5.3 | | Pragma | standard | Section 5.4 |
| Pragma | standard | Section 5.4 | | Warning | obsoleted | Section 5.5 |
| Warning | obsoleted | Section 5.5 | +---------------+-----------+-------------+
+---------------+-----------+--------------+
Table 1 Table 1
5.1. Age 5.1. Age
The "Age" header field conveys the sender's estimate of the amount of The "Age" header field conveys the sender's estimate of the amount of
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
skipping to change at page 23, line 16 skipping to change at page 23, line 22
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
unidirectional in that the presence of a directive in a request does unidirectional in that the presence of a directive in a request does
not imply that the same directive is present in the response, or to not imply that the same directive is present in the response, or to
be repeated in it. be repeated in it.
See Section 5.2.3 for information about how Cache-Control directives See Section 5.2.3 for information about how Cache-Control directives
defined elsewhere are handled. defined elsewhere are handled.
Note: Some HTTP/1.0 caches might not implement Cache-Control. | *Note:* Some HTTP/1.0 caches might not implement Cache-Control.
A proxy, whether or not it implements a cache, MUST pass cache A proxy, whether or not it implements a cache, MUST pass cache
directives through in forwarded messages, regardless of their directives through in forwarded messages, regardless of their
significance to that application, since the directives might be significance to that application, since the directives might be
applicable to all recipients along the request/response chain. It is applicable to all recipients along the request/response chain. It is
not possible to target a directive to a specific cache. not possible to target a directive to a specific cache.
Cache directives are identified by a token, to be compared case- Cache directives are identified by a token, to be compared case-
insensitively, and have an optional argument, that can use both token insensitively, and have an optional argument, that can use both token
and quoted-string syntax. For the directives defined below that and quoted-string syntax. For the directives defined below that
define arguments, recipients ought to accept both forms, even if a define arguments, recipients ought to accept both forms, even if a
specific form is required for generation. specific form is required for generation.
Cache-Control = 1#cache-directive Cache-Control = 1#cache-directive
cache-directive = token [ "=" ( token / quoted-string ) ] cache-directive = token [ "=" ( token / quoted-string ) ]
For the cache directives defined below, no argument is defined (nor For the cache directives defined below, no argument is defined (nor
allowed) unless stated otherwise. allowed) unless stated otherwise.
+------------------+-----------------------------------+ +------------------+----------------------------------+
| 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.9 | | 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.1 | | must-understand | Section 5.2.2.2 |
| must-understand | Section 5.2.2.2 | | no-cache | Section 5.2.1.4, Section 5.2.2.3 |
| no-cache | Section 5.2.1.4, Section 5.2.2.3 | | no-store | Section 5.2.1.5, Section 5.2.2.4 |
| no-store | Section 5.2.1.5, Section 5.2.2.4 | | no-transform | Section 5.2.1.6, Section 5.2.2.5 |
| no-transform | Section 5.2.1.6, Section 5.2.2.5 | | 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.6 | | s-maxage | Section 5.2.2.10 |
| s-maxage | Section 5.2.2.10 | +------------------+----------------------------------+
+------------------+-----------------------------------+
Table 2 Table 2
5.2.1. Request Cache-Control Directives 5.2.1. Request Cache-Control Directives
This section defines cache request directives. They are advisory; This section defines cache request directives. They are advisory;
caches MAY implement them, but are not required to. caches MAY implement them, but are not required to.
5.2.1.1. max-age 5.2.1.1. max-age
Argument syntax: Argument syntax:
skipping to change at page 27, line 45 skipping to change at page 27, line 45
certain header fields in a response, while still allowing caching of certain header fields in a response, while still allowing caching of
the rest of the response. the rest of the response.
The field names given are not limited to the set of header fields The field names given are not limited to the set of header fields
defined by this specification. Field names are case-insensitive. defined by this specification. Field names are case-insensitive.
This directive uses the quoted-string form of the argument syntax. A This directive uses the quoted-string form of the argument syntax. A
sender SHOULD NOT generate the token form (even if quoting appears sender SHOULD NOT generate the token form (even if quoting appears
not to be needed for single-entry lists). not to be needed for single-entry lists).
Note: Although it has been back-ported to many implementations, some *Note:* Although it has been back-ported to many implementations,
HTTP/1.0 caches will not recognize or obey this directive. Also, the some HTTP/1.0 caches will not recognize or obey this directive.
qualified form of the directive is often handled by caches as if an Also, the qualified form of the directive is often handled by caches
unqualified no-cache directive was received; i.e., the special as if an unqualified no-cache directive was received; i.e., the
handling for the qualified form is not widely implemented. special handling for the qualified form is not widely implemented.
5.2.2.4. no-store 5.2.2.4. 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-
skipping to change at page 29, line 21 skipping to change at page 29, line 26
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. 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
content. Also, the qualified form of the directive is often handled content. Also, the qualified form of the directive is often handled
by caches as if an unqualified private directive was received; i.e., by caches as if an unqualified private directive was received; i.e.,
the special handling for the qualified form is not widely the special handling for the qualified form is not widely
implemented. implemented.
5.2.2.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
skipping to change at page 32, line 50 skipping to change at page 33, line 14
5.4. Pragma 5.4. Pragma
The "Pragma" header field was defined for HTTP/1.0 caches, so that The "Pragma" header field was defined for HTTP/1.0 caches, so that
clients could specify a "no-cache" request (as Cache-Control was not clients could specify a "no-cache" request (as Cache-Control was not
defined until HTTP/1.1). defined until HTTP/1.1).
However, support for Cache-Control is now widespread. As a result, However, support for Cache-Control is now widespread. As a result,
this specification deprecates Pragma. this specification deprecates Pragma.
Note: Because the meaning of "Pragma: no-cache" in responses was | *Note:* Because the meaning of "Pragma: no-cache" in responses
never specified, it does not provide a reliable replacement for | was never specified, it does not provide a reliable replacement
"Cache-Control: no-cache" in them. | for "Cache-Control: no-cache" in them.
5.5. Warning 5.5. Warning
The "Warning" header field was used to carry additional information The "Warning" header field was used to carry additional information
about the status or transformation of a message that might not be about the status or transformation of a message that might not be
reflected in the status code. This specification obsoletes it, as it reflected in the status code. This specification obsoletes it, as it
is not widely generated or surfaced to users. The information it is not widely generated or surfaced to users. The information it
carried can be gleaned from examining other header fields, such as carried can be gleaned from examining other header fields, such as
Age. Age.
skipping to change at page 35, line 29 skipping to change at page 35, line 47
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. F. Reschke,
Ed., "HTTP/1.1 Messaging", draft-ietf-httpbis-messaging-09 Ed., "HTTP/1.1 Messaging", Work in Progress, Internet-
(work in progress), July 2020. Draft, draft-ietf-httpbis-messaging-10, July 12, 2020,
<https://tools.ietf.org/html/draft-ietf-httpbis-messaging-
10>.
[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 36, line 10 skipping to change at page 36, line 29
[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. F. Reschke,
Ed., "HTTP Semantics", draft-ietf-httpbis-semantics-09 Ed., "HTTP Semantics", Work in Progress, Internet-Draft,
(work in progress), July 2020. draft-ietf-httpbis-semantics-10, July 12, 2020,
<https://tools.ietf.org/html/draft-ietf-httpbis-semantics-
10>.
[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 36, line 39 skipping to change at page 37, line 14
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>. <https://www.rfc-editor.org/info/rfc5905>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011, DOI 10.17487/RFC6265, April 2011,
<https://www.rfc-editor.org/info/rfc6265>. <https://www.rfc-editor.org/info/rfc6265>.
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. F. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP): Caching", Ed., "Hypertext Transfer Protocol (HTTP): Caching",
RFC 7234, DOI 10.17487/RFC7234, June 2014, RFC 7234, DOI 10.17487/RFC7234, June 2014,
<https://www.rfc-editor.org/info/rfc7234>. <https://www.rfc-editor.org/info/rfc7234>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
Appendix A. Collected ABNF Appendix A. Collected ABNF
skipping to change at page 37, line 49 skipping to change at page 38, line 24
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. 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.
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 41, line 17 skipping to change at page 41, line 40
(<https://github.com/httpwg/http-core/issues/320>) (<https://github.com/httpwg/http-core/issues/320>)
o In Section 3.2, move definition of "complete" into semantics o In Section 3.2, 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>)
Index C.11. Since draft-ietf-httpbis-cache-09
A
Age header field 22
age 12
C
Cache-Control header field 23
cache 4
cache key 6
E
Expires header field 31
explicit expiration time 12
F
Fields
Age 22
Cache-Control 23
Expires 31
Pragma 32
Warning 33
fresh 12
freshness lifetime 12
G
Grammar
Age 22
ALPHA 5
Cache-Control 23
cache-directive 23
CR 5
CRLF 5
CTL 5
delta-seconds 6
DIGIT 5
DQUOTE 5
Expires 32
HEXDIG 5
HTAB 5
LF 5
OCTET 5
SP 5
VCHAR 5
H
Header Fields
Age 22
Cache-Control 23
Expires 31
Pragma 32
Warning 33
heuristic expiration time 12
heuristically cacheable 14
M
max-age (cache directive) 24, 29
max-stale (cache directive) 24
min-fresh (cache directive) 25
must-revalidate (cache directive) 26
must-understand (cache directive) 27
N
no-cache (cache directive) 25, 27
no-store (cache directive) 25, 28
no-transform (cache directive) 26, 28
O
only-if-cached (cache directive) 26
P
Pragma header field 32
private (cache directive) 28
private cache 4
proxy-revalidate (cache directive) 29
public (cache directive) 28
S
s-maxage (cache directive) 30
shared cache 4
stale 12
strong validator 20
V
validator 17
W o Switch to xml2rfc v3 mode for draft generation
Warning header field 33 (<https://github.com/httpwg/http-core/issues/394>)
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
United States of America United States of America
EMail: fielding@gbiv.com Email: fielding@gbiv.com
URI: https://roy.gbiv.com/ URI: https://roy.gbiv.com/
Mark Nottingham (editor) Mark Nottingham (editor)
Fastly Fastly
EMail: mnot@mnot.net Email: mnot@mnot.net
URI: https://www.mnot.net/ URI: https://www.mnot.net/
Julian F. Reschke (editor) Julian F. Reschke (editor)
greenbytes GmbH greenbytes GmbH
Hafenweg 16 Hafenweg 16
Muenster 48155 48155 M√ľnster
Germany Germany
EMail: julian.reschke@greenbytes.de Email: julian.reschke@greenbytes.de
URI: https://greenbytes.de/tech/webdav/ URI: https://greenbytes.de/tech/webdav/
 End of changes. 40 change blocks. 
190 lines changed or deleted 105 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/