draft-ietf-httpbis-cache-12.txt   draft-ietf-httpbis-cache-latest.txt 
HTTP Working Group R. Fielding, Ed. HTTP Working Group R. Fielding, Ed.
Internet-Draft Adobe Internet-Draft Adobe
Obsoletes: 7234 (if approved) M. Nottingham, Ed. Obsoletes: 7234 (if approved) M. Nottingham, Ed.
Intended status: Standards Track Fastly Intended status: Standards Track Fastly
Expires: April 5, 2021 J. Reschke, Ed. Expires: May 27, 2021 J. Reschke, Ed.
greenbytes greenbytes
October 2, 2020 November 23, 2020
HTTP Caching HTTP Caching
draft-ietf-httpbis-cache-12 draft-ietf-httpbis-cache-latest
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is a stateless application- The Hypertext Transfer Protocol (HTTP) is a stateless application-
level protocol for distributed, collaborative, hypertext information level protocol for distributed, collaborative, hypertext information
systems. This document defines HTTP caches and the associated header systems. This document defines HTTP caches and the associated header
fields that control cache behavior or indicate cacheable response fields that control cache behavior or indicate cacheable response
messages. messages.
This document obsoletes RFC 7234. This document obsoletes RFC 7234.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
This note is to be removed before publishing as an RFC. This note is to be removed before publishing as an RFC.
Discussion of this draft takes place on the HTTP working group Discussion of this draft takes place on the HTTP working group
mailing list (ietf-http-wg@w3.org), which is archived at mailing list (ietf-http-wg@w3.org), which is archived at
<https://lists.w3.org/Archives/Public/ietf-http-wg/>. <https://lists.w3.org/Archives/Public/ietf-http-wg/>.
Working Group information can be found at <https://httpwg.org/>; Working Group information can be found at <https://httpwg.org/>;
source code and issues list for this draft can be found at source code and issues list for this draft can be found at
<https://github.com/httpwg/http-core>. <https://github.com/httpwg/http-core>.
The changes in this draft are summarized in Appendix C.13. The changes in this draft are summarized in Appendix C.14.
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 April 5, 2021. This Internet-Draft will expire on May 27, 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 43 skipping to change at page 2, line 43
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. 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 . . . . . . . . . . . . . . . . . . . . . . 5
2. Overview of Cache Operation . . . . . . . . . . . . . . . . . 6 2. Overview of Cache Operation . . . . . . . . . . . . . . . . . 6
3. Storing Responses in Caches . . . . . . . . . . . . . . . . . 7 3. Storing Responses in Caches . . . . . . . . . . . . . . . . . 7
3.1. Storing Header and Trailer Fields . . . . . . . . . . . . 8 3.1. Storing Header and Trailer Fields . . . . . . . . . . . . 8
3.2. 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 . . . . . . . 9
3.4. Combining Partial Content . . . . . . . . . . . . . . . . 10 3.4. Combining Partial Content . . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . 21 4.3.5. Freshening Responses with HEAD . . . . . . . . . . . 21
4.4. Invalidation . . . . . . . . . . . . . . . . . . . . . . 21 4.4. Invalidation . . . . . . . . . . . . . . . . . . . . . . 22
5. Field Definitions . . . . . . . . . . . . . . . . . . . . . . 22 5. Field Definitions . . . . . . . . . . . . . . . . . . . . . . 23
5.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 5.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
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.2. max-stale . . . . . . . . . . . . . . . . . . . . 24
5.2.1.3. min-fresh . . . . . . . . . . . . . . . . . . . . 25
5.2.1.4. no-cache . . . . . . . . . . . . . . . . . . . . 25
5.2.1.5. no-store . . . . . . . . . . . . . . . . . . . . 25
5.2.1.6. no-transform . . . . . . . . . . . . . . . . . . 26
5.2.1.7. only-if-cached . . . . . . . . . . . . . . . . . 26
5.2.2. Response Cache-Control Directives . . . . . . . . . . 26 5.2.2. Response Cache-Control Directives . . . . . . . . . . 26
5.2.2.1. must-revalidate . . . . . . . . . . . . . . . . . 26
5.2.2.2. must-understand . . . . . . . . . . . . . . . . . 27
5.2.2.3. no-cache . . . . . . . . . . . . . . . . . . . . 27
5.2.2.4. no-store . . . . . . . . . . . . . . . . . . . . 28
5.2.2.5. no-transform . . . . . . . . . . . . . . . . . . 28
5.2.2.6. public . . . . . . . . . . . . . . . . . . . . . 28
5.2.2.7. private . . . . . . . . . . . . . . . . . . . . . 28
5.2.2.8. proxy-revalidate . . . . . . . . . . . . . . . . 29
5.2.2.9. max-age . . . . . . . . . . . . . . . . . . . . . 29
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 . . . . . . . . . . . . . . . . . . . . . . . . . 32 5.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . 33 5.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.5. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 33 5.5. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 33
6. Relationship to Applications . . . . . . . . . . . . . . . . 33 6. Relationship to Applications and Other Caches . . . . . . . . 33
7. Security Considerations . . . . . . . . . . . . . . . . . . . 34 7. Security Considerations . . . . . . . . . . . . . . . . . . . 33
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 . . . . . . . . . . . . 35 7.3. Caching of Sensitive Information . . . . . . . . . . . . 34
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
8.1. Field Registration . . . . . . . . . . . . . . . . . . . 35 8.1. Field Name 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 . . . . . . . . . . . . . . . . . . . 36
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
9.1. Normative References . . . . . . . . . . . . . . . . . . 35 9.1. Normative References . . . . . . . . . . . . . . . . . . 36
9.2. Informative References . . . . . . . . . . . . . . . . . 36 9.2. Informative References . . . . . . . . . . . . . . . . . 37
Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 37 Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 38
Appendix B. Changes from RFC 7234 . . . . . . . . . . . . . . . 37 Appendix B. Changes from RFC 7234 . . . . . . . . . . . . . . . 38
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 38 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 39
C.1. Between RFC7234 and draft 00 . . . . . . . . . . . . . . 38 C.1. Between RFC7234 and draft 00 . . . . . . . . . . . . . . 39
C.2. Since draft-ietf-httpbis-cache-00 . . . . . . . . . . . . 39 C.2. Since draft-ietf-httpbis-cache-00 . . . . . . . . . . . . 39
C.3. Since draft-ietf-httpbis-cache-01 . . . . . . . . . . . . 39 C.3. Since draft-ietf-httpbis-cache-01 . . . . . . . . . . . . 40
C.4. Since draft-ietf-httpbis-cache-02 . . . . . . . . . . . . 39 C.4. Since draft-ietf-httpbis-cache-02 . . . . . . . . . . . . 40
C.5. Since draft-ietf-httpbis-cache-03 . . . . . . . . . . . . 39 C.5. Since draft-ietf-httpbis-cache-03 . . . . . . . . . . . . 40
C.6. Since draft-ietf-httpbis-cache-04 . . . . . . . . . . . . 40 C.6. Since draft-ietf-httpbis-cache-04 . . . . . . . . . . . . 41
C.7. Since draft-ietf-httpbis-cache-05 . . . . . . . . . . . . 40 C.7. Since draft-ietf-httpbis-cache-05 . . . . . . . . . . . . 41
C.8. Since draft-ietf-httpbis-cache-06 . . . . . . . . . . . . 40 C.8. Since draft-ietf-httpbis-cache-06 . . . . . . . . . . . . 41
C.9. Since draft-ietf-httpbis-cache-07 . . . . . . . . . . . . 41 C.9. Since draft-ietf-httpbis-cache-07 . . . . . . . . . . . . 42
C.10. Since draft-ietf-httpbis-cache-08 . . . . . . . . . . . . 41 C.10. Since draft-ietf-httpbis-cache-08 . . . . . . . . . . . . 42
C.11. Since draft-ietf-httpbis-cache-09 . . . . . . . . . . . . 41 C.11. Since draft-ietf-httpbis-cache-09 . . . . . . . . . . . . 42
C.12. Since draft-ietf-httpbis-cache-10 . . . . . . . . . . . . 41 C.12. Since draft-ietf-httpbis-cache-10 . . . . . . . . . . . . 42
C.13. Since draft-ietf-httpbis-cache-11 . . . . . . . . . . . . 42 C.13. Since draft-ietf-httpbis-cache-11 . . . . . . . . . . . . 42
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 42 C.14. Since draft-ietf-httpbis-cache-12 . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
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 5, line 47 skipping to change at page 5, line 31
This specification uses the Augmented Backus-Naur Form (ABNF) This specification uses the Augmented Backus-Naur Form (ABNF)
notation of [RFC5234], extended with the notation for case- notation of [RFC5234], extended with the notation for case-
sensitivity in strings defined in [RFC7405]. sensitivity in strings defined in [RFC7405].
It also uses a list extension, defined in Section 5.7.1 of It also uses a list extension, defined in Section 5.7.1 of
[Semantics], that allows for compact definition of comma-separated [Semantics], that allows for compact definition of comma-separated
lists using a '#' operator (similar to how the '*' operator indicates lists using a '#' operator (similar to how the '*' operator indicates
repetition). Appendix A shows the collected grammar with all list repetition). Appendix A shows the collected grammar with all list
operators expanded to standard ABNF notation. operators expanded to standard ABNF notation.
The following core rules are included by reference, as defined in The following core rule is included by reference, as defined in
[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF [RFC5234], Appendix B.1: DIGIT (decimal 0-9).
(CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line
feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any
visible [USASCII] character).
[Semantics] defines the following rules: [Semantics] defines the following rules:
HTTP-date = <HTTP-date, see [Semantics], Section 5.7.7> HTTP-date = <HTTP-date, see [Semantics], Section 5.7.7>
OWS = <OWS, see [Semantics], Section 5.7.3> OWS = <OWS, see [Semantics], Section 5.7.3>
field-name = <field-name, see [Semantics], Section 5.4.3> field-name = <field-name, see [Semantics], Section 5.4.3>
quoted-string = <quoted-string, see [Semantics], Section 5.7.4> quoted-string = <quoted-string, see [Semantics], Section 5.7.4>
token = <token, see [Semantics], Section 5.7.2> token = <token, see [Semantics], Section 5.7.2>
1.3. Delta Seconds 1.3. Delta Seconds
skipping to change at page 8, line 44 skipping to change at page 8, line 27
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 response 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 Appendix of [Messaging] to be removed before it are required by Section 6.4.1 of [Semantics] to be removed
forwarding the message. This MAY be implemented by doing so before forwarding the message. This MAY be implemented by doing
before storage. so before storage.
o Likewise, some fields' semantics require them to be removed before o Likewise, some fields' semantics require them to be removed before
forwarding the message, and this MAY be implemented by doing so forwarding the message, and this MAY be implemented by doing so
before storage; see Appendix of [Messaging] for some examples. before storage; see Section 6.4.1 of [Semantics] for some
examples.
o Header fields that are specific to a client's proxy configuration o Header fields that are specific to a client's proxy configuration
MUST NOT be stored, unless the cache incorporates the identity of MUST NOT be stored, unless the cache incorporates the identity of
the proxy into the cache key. Effectively, this is limited to the proxy into the cache key. Effectively, this is limited to
Proxy-Authenticate (Section 10.7.1 of [Semantics]), Proxy- Proxy-Authenticate (Section 10.7.1 of [Semantics]), Proxy-
Authentication-Info (Section 10.7.3 of [Semantics]), and Proxy- Authentication-Info (Section 10.7.3 of [Semantics]), and Proxy-
Authorization (Section 10.7.2 of [Semantics]). Authorization (Section 10.7.2 of [Semantics]).
Caches MAY either store trailer fields separate from header fields, Caches MAY either store trailer fields separate from header fields,
or discard them. Caches MUST NOT combine trailer fields with header or discard them. Caches MUST NOT combine trailer fields with header
skipping to change at page 11, line 18 skipping to change at page 11, line 5
stored response's current_age; see Section 4.2.3. stored response's current_age; see Section 4.2.3.
A cache MUST write through requests with methods that are unsafe A cache MUST write through requests with methods that are unsafe
(Section 8.2.1 of [Semantics]) to the origin server; i.e., a cache is (Section 8.2.1 of [Semantics]) to the origin server; i.e., a cache is
not allowed to generate a reply to such a request before having not allowed to generate a reply to such a request before having
forwarded the request and having received a corresponding response. forwarded the request and having received a corresponding response.
Also, note that unsafe requests might invalidate already-stored Also, note that unsafe requests might invalidate already-stored
responses; see Section 4.4. responses; see Section 4.4.
A response that is stored or storable can be used to satisfy multiple
requests, provided that it is allowed to reuse that response for the
requests in question. This enables caches to "collapse" multiple
incoming requests into a single forward request upon a cache miss,
thereby reducing load on the origin server and network. However,
note that if the response returned is not able to be used for some or
all of the collapsed requests, additional latency might be
introduced, because they will need to be forwarded to be satisfied.
When more than one suitable response is stored, a cache MUST use the When more than one suitable response is stored, a cache MUST use the
most recent one (as determined by the Date header field). It can most recent one (as determined by the Date header field). It can
also forward the request with "Cache-Control: max-age=0" or "Cache- also forward the request with "Cache-Control: max-age=0" or "Cache-
Control: no-cache" to disambiguate which response to use. Control: no-cache" to disambiguate which response to use.
A cache that does not have a clock available MUST NOT use stored A cache that does not have a clock available MUST NOT use stored
responses without revalidating them upon every use. responses without revalidating them upon every use.
4.1. Calculating Cache Keys with Vary 4.1. Calculating Cache Keys with Vary
skipping to change at page 12, line 19 skipping to change at page 12, line 12
A Vary header field value containing a member "*" always fails to A Vary header field value containing a member "*" always fails to
match. match.
The stored response with matching selecting header fields is known as The stored response with matching selecting header fields is known as
the selected response. the selected response.
If multiple selected responses are available (potentially including If multiple selected responses are available (potentially including
responses without a Vary header field), the cache will need to choose responses without a Vary header field), the cache will need to choose
one to use. When a selecting header field has a known mechanism for one to use. When a selecting header field has a known mechanism for
doing so (e.g., qvalues on Accept and similar request header fields), doing so (e.g., qvalues on Accept and similar request header fields),
that mechanism MAY be used to select preferred responses; of the that mechanism MAY be used to select a preferred response. If such a
remainder, the most recent response (as determined by the Date header mechanism is not available, or leads to equally preferred responses,
field) is used, as per Section 4. the most recent response (as determined by the Date header field) is
used, as per Section 4.
Note that in practice, some resources might send the Vary header Some resources mistakenly omit the Vary header field from their
field on responses inconsistently. When a cache has multiple default response (i.e., the one sent when no more preferable response
responses for a target URI, and one or more omits the Vary header is available), selecting it for requests to that resource even when
field, it SHOULD use the most recent non-empty value available to more preferable responses are available. When a cache has multiple
select an appropriate response for the request. responses for a target URI and one or more omits the Vary header
field, it SHOULD use the most recent (see Section 4.2.3) valid Vary
field value available to select an appropriate response for the
request.
If no selected response is available, the cache cannot satisfy the If no selected response is available, the cache cannot satisfy the
presented request. Typically, it is forwarded to the origin server presented request. Typically, it is forwarded to the origin server
in a (possibly conditional; see Section 4.3) request. in a (possibly conditional; see Section 4.3) request.
4.2. Freshness 4.2. Freshness
A fresh response is one whose age has not yet exceeded its freshness A fresh response is one whose age has not yet exceeded its freshness
lifetime. Conversely, a stale response is one where it has. lifetime. Conversely, a stale response is one where it has.
skipping to change at page 13, line 38 skipping to change at page 13, line 33
defined in Section 4.2.3. defined in Section 4.2.3.
Clients can send the max-age or min-fresh request directives Clients can send the max-age or min-fresh request directives
(Section 5.2.1) to constrain or relax freshness calculations for the (Section 5.2.1) to constrain or relax freshness calculations for the
corresponding response. However, caches are not required to honor corresponding response. However, caches are not required to honor
them. them.
When calculating freshness, to avoid common problems in date parsing: When calculating freshness, to avoid common problems in date parsing:
o Although all date formats are specified to be case-sensitive, a o Although all date formats are specified to be case-sensitive, a
cache recipient SHOULD match day, week, and time-zone names case- cache recipient SHOULD match the field value case-insensitively.
insensitively.
o If a cache recipient's internal implementation of time has less o If a cache recipient's internal implementation of time has less
resolution than the value of an HTTP-date, the recipient MUST resolution than the value of an HTTP-date, the recipient MUST
internally represent a parsed Expires date as the nearest time internally represent a parsed Expires date as the nearest time
equal to or earlier than the received value. equal to or earlier than the received value.
o A cache recipient MUST NOT allow local time zones to influence the o A cache recipient MUST NOT allow local time zones to influence the
calculation or comparison of an age or expiration time. calculation or comparison of an age or expiration time.
o A cache recipient SHOULD consider a date with a zone abbreviation o A cache recipient SHOULD consider a date with a zone abbreviation
other than GMT or UTC to be invalid for calculating expiration. other than "GMT" to be invalid for calculating expiration.
Note that freshness applies only to cache operation; it cannot be Note that freshness applies only to cache operation; it cannot be
used to force a user agent to refresh its display or reload a used to force a user agent to refresh its display or reload a
resource. See Section 6 for an explanation of the difference between resource. See Section 6 for an explanation of the difference between
caches and history mechanisms. caches and history mechanisms.
4.2.1. Calculating Freshness Lifetime 4.2.1. Calculating Freshness Lifetime
A cache can calculate the freshness lifetime (denoted as A cache can calculate the freshness lifetime (denoted as
freshness_lifetime) of a response by using the first match of: freshness_lifetime) of a response by using the first match of:
skipping to change at page 14, line 32 skipping to change at page 14, line 27
its value minus the value of the Date response header field, or its value minus the value of the Date response header field, or
o Otherwise, no explicit expiration time is present in the response. o Otherwise, no explicit expiration time is present in the response.
A heuristic freshness lifetime might be applicable; see A heuristic freshness lifetime might be applicable; see
Section 4.2.2. Section 4.2.2.
Note that this calculation is not vulnerable to clock skew, since all Note that this calculation is not vulnerable to clock skew, since all
of the information comes from the origin server. of the information comes from the origin server.
When there is more than one value present for a given directive When there is more than one value present for a given directive
(e.g., two Expires header fields, multiple Cache-Control: max-age (e.g., two Expires header field lines or multiple Cache-Control: max-
directives), the directive's value is considered invalid. Caches are age directives), either the first occurrence should be used, or the
encouraged to consider responses that have invalid freshness response should be considered stale. If directives conflict (e.g.,
information to be stale. both max-age and no-cache are present), the most restrictive
directive should be honored. Caches are encouraged to consider
responses that have invalid freshness information (e.g., a max-age
directive with non-integer content) to be stale.
4.2.2. Calculating Heuristic Freshness 4.2.2. Calculating Heuristic Freshness
Since origin servers do not always provide explicit expiration times, Since origin servers do not always provide explicit expiration times,
a cache MAY assign a heuristic expiration time when an explicit time a cache MAY assign a heuristic expiration time when an explicit time
is not specified, employing algorithms that use other header field is not specified, employing algorithms that use other field values
values (such as the Last-Modified time) to estimate a plausible (such as the Last-Modified time) to estimate a plausible expiration
expiration time. This specification does not provide specific time. This specification does not provide specific algorithms, but
algorithms, but does impose worst-case constraints on their results. does impose worst-case constraints on their results.
A cache MUST NOT use heuristics to determine freshness when an A cache MUST NOT use heuristics to determine freshness when an
explicit expiration time is present in the stored response. Because explicit expiration time is present in the stored response. Because
of the requirements in Section 3, this means that heuristics can only of the requirements in Section 3, this means that heuristics can only
be used on responses without explicit freshness whose status codes be used on responses without explicit freshness whose status codes
are defined as "heuristically cacheable" (e.g., see Section 14.1 of are defined as "heuristically cacheable" (e.g., see Section 14.1 of
[Semantics]), and those responses without explicit freshness that [Semantics]), and those responses without explicit freshness that
have been marked as explicitly cacheable (e.g., with a "public" have been marked as explicitly cacheable (e.g., with a "public"
response directive). response directive).
skipping to change at page 17, line 6 skipping to change at page 16, line 43
resident_time = now - response_time; resident_time = now - response_time;
current_age = corrected_initial_age + resident_time; current_age = corrected_initial_age + resident_time;
4.2.4. Serving Stale Responses 4.2.4. Serving Stale Responses
A "stale" response is one that either has explicit expiry information A "stale" response is one that either has explicit expiry information
or is allowed to have heuristic expiry calculated, but is not fresh or is allowed to have heuristic expiry calculated, but is not fresh
according to the calculations in Section 4.2. according to the calculations in Section 4.2.
A cache MUST NOT generate a stale response if it is prohibited by an A cache MUST NOT generate a stale response if it is prohibited by an
explicit in-protocol directive (e.g., by a "no-store" or "no-cache" explicit in-protocol directive (e.g., by a "no-cache" cache
cache directive, a "must-revalidate" cache-response-directive, or an directive, a "must-revalidate" cache-response-directive, or an
applicable "s-maxage" or "proxy-revalidate" cache-response-directive; applicable "s-maxage" or "proxy-revalidate" cache-response-directive;
see Section 5.2.2). see Section 5.2.2).
A cache MUST NOT generate a stale response unless it is disconnected A cache MUST NOT generate a stale response unless it is disconnected
or doing so is explicitly permitted by the client or origin server or doing so is explicitly permitted by the client or origin server
(e.g., by the max-stale request directive in Section 5.2.1, by (e.g., by the max-stale request directive in Section 5.2.1, by
extension directives such as those defined in [RFC5861], or by extension directives such as those defined in [RFC5861], or by
configuration in accordance with an out-of-band contract). configuration in accordance with an out-of-band contract).
4.3. Validation 4.3. Validation
skipping to change at page 19, line 23 skipping to change at page 19, line 28
(Section 4.3.4). (Section 4.3.4).
If an If-None-Match header field is not present, a request containing If an If-None-Match header field is not present, a request containing
an If-Modified-Since header field (Section 12.1.3 of [Semantics]) an If-Modified-Since header field (Section 12.1.3 of [Semantics])
indicates that the client wants to validate one or more of its own indicates that the client wants to validate one or more of its own
stored responses by modification date. A cache recipient SHOULD stored responses by modification date. A cache recipient SHOULD
generate a 304 (Not Modified) response (using the metadata of the generate a 304 (Not Modified) response (using the metadata of the
selected stored response) if one of the following cases is true: 1) selected stored response) if one of the following cases is true: 1)
the selected stored response has a Last-Modified field value that is the selected stored response has a Last-Modified field value that is
earlier than or equal to the conditional timestamp; 2) no Last- earlier than or equal to the conditional timestamp; 2) no Last-
Modified field is present in the selected stored response, but it has Modified header field is present in the selected stored response, but
a Date field value that is earlier than or equal to the conditional it has a Date field value that is earlier than or equal to the
timestamp; or, 3) neither Last-Modified nor Date is present in the conditional timestamp; or, 3) neither Last-Modified nor Date is
selected stored response, but the cache recorded it as having been present in the selected stored response, but the cache recorded it as
received at a time earlier than or equal to the conditional having been received at a time earlier than or equal to the
timestamp. conditional timestamp.
A cache that implements partial responses to range requests, as A cache that implements partial responses to range requests, as
defined in Section 13.2 of [Semantics], also needs to evaluate a defined in Section 13.2 of [Semantics], also needs to evaluate a
received If-Range header field (Section 12.1.5 of [Semantics]) received If-Range header field (Section 12.1.5 of [Semantics])
regarding its selected stored response. regarding its selected stored response.
4.3.3. Handling a Validation Response 4.3.3. Handling a Validation Response
Cache handling of a response to a conditional request depends upon Cache handling of a response to a conditional request depends upon
its status code: its status code:
o A 304 (Not Modified) response status code indicates that the o A 304 (Not Modified) response status code indicates that the
stored response can be updated and reused; see Section 4.3.4. stored response can be updated and reused; see Section 4.3.4.
o A full response (i.e., one with a payload body) indicates that o A full response (i.e., one with a payload body) indicates that
none of the stored responses nominated in the conditional request none of the stored responses nominated in the conditional request
is suitable. Instead, the cache MUST use the full response to is suitable. Instead, the cache MUST use the full response to
satisfy the request and MAY replace the stored response(s). satisfy the request. The cache MAY store such a full response,
subject to its constraints (see Section 3).
o However, if a cache receives a 5xx (Server Error) response while o However, if a cache receives a 5xx (Server Error) response while
attempting to validate a response, it can either forward this attempting to validate a response, it can either forward this
response to the requesting client, or act as if the server failed response to the requesting client, or act as if the server failed
to respond. In the latter case, the cache MAY send a previously to respond. In the latter case, the cache can send a previously
stored response (see Section 4.2.4). stored response, subject to its constraints on doing so (see
Section 4.2.4), or retry the validation request.
4.3.4. Freshening Stored Responses upon Validation 4.3.4. Freshening Stored Responses upon Validation
When a cache receives a 304 (Not Modified) response and already has When a cache receives a 304 (Not Modified) response and already has
one or more stored 200 (OK) responses for the applicable cache key, one or more stored 200 (OK) responses for the applicable cache key,
the cache needs to identify which (if any) are to be updated by the the cache needs to identify which (if any) are to be updated by the
new information provided, and then do so. new information provided, and then do so.
The stored response(s) to update are identified by using the first The stored response(s) to update are identified by using the first
match (if any) of: match (if any) of:
skipping to change at page 20, line 46 skipping to change at page 20, line 47
source other than the Last-Modified response header field), and source other than the Last-Modified response header field), and
there is only one stored response, and that stored response also there is only one stored response, and that stored response also
lacks a validator, then that stored response is identified for lacks a validator, then that stored response is identified for
update. 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, with the following exceptions: stored response, with the following exceptions:
o The exceptions to header field storage in Section 3.1 also apply o Header fields excepted from storage in Section 3.1,
to header field updates.
o Caches MUST NOT update the following header fields: Content- o Header fields that the cache's stored representation of the
Encoding, Content-Length, Content-MD5 (Section 14.15 of response depends upon, as described below,
[RFC2616]), Content-Range, ETag.
o Header fields that are automatically processed and removed by the
recipient, as described below, and
o The Content-Length header field.
In some cases, caches (especially in user agents) store processed
representations of the received response, rather than the response
itself, and updating header fields that affect that processing can
result in inconsistent behavior and security issues. Caches in this
situation MAY omit these header fields from updating stored
representations on an exceptional basis, but SHOULD limit such
omission to those fields necessary to assure integrity of the stored
representation.
For example, a browser might store a response's body after removing
content-codings, thereby making its metadata inaccurate. Updating
that stored metadata with a different Content-Encoding header field
would be problematic. Likewise, a browser might store a post-parse
tree representation of HTML, rather than the body received in the
response; updating the Content-Type header field would not be
workable in this case, because any assumptions about the format made
in parsing would now be invalid.
Furthermore, some fields are automatically processed and removed by
the HTTP implementation; for example, the Content-Range header field.
Implementations MAY automatically omit such header fields from
updates, even when the processing does not actually occur.
Note that the Content-* prefix is not a signal that a header field is
omitted from update; it is only a convention for naming content-
related fields.
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.
skipping to change at page 21, line 41 skipping to change at page 22, line 26
fields in the stored response (subject to the exceptions in fields in the stored response (subject to the exceptions in
Section 4.3.4) and append new header fields to the stored response's Section 4.3.4) and append new header fields to the stored response's
header section unless otherwise restricted by the Cache-Control header section unless otherwise restricted by the Cache-Control
header field. header field.
4.4. Invalidation 4.4. Invalidation
Because unsafe request methods (Section 8.2.1 of [Semantics]) such as Because unsafe request methods (Section 8.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 are required to invalidate stored origin server, intervening caches are required to invalidate stored
responses to keep their contents up to date. Invalidate means that responses to keep their contents up to date.
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.
Note that this does not guarantee that all appropriate responses are
invalidated globally; a state-changing request would only invalidate
responses in the caches it travels through.
A cache MUST invalidate the target URI (Section 6.1 of [Semantics]) A cache MUST invalidate the target URI (Section 6.1 of [Semantics])
and the URI(s) in the Location and Content-Location response header when a non-error status code is received in response to an unsafe
fields (if present) when a non-error status code is received in request method (including methods whose safety is unknown).
response to an unsafe request method.
However, a cache MUST NOT invalidate a URI from a Location or A cache MAY invalidate other URIs when a non-error status code is
Content-Location response header field if the host part of that URI received in response to an unsafe request method (including methods
differs from the host part in the target URI (Section 6.1 of whose safety is unknown). In particular, the URI(s) in the Location
[Semantics]). This helps prevent denial-of-service attacks. and Content-Location response header fields (if present) are
candidates for invalidation; other URIs might be discovered through
mechanisms not specified in this document. However, a cache MUST NOT
trigger an invalidation under these conditions if the origin
(Section 4.3.1 of [Semantics]) of the URI to be invalidated differs
from that of the target URI (Section 6.1 of [Semantics]). This helps
prevent denial-of-service attacks.
A cache MUST invalidate the target URI (Section 6.1 of [Semantics]) Invalidate means that the cache will either remove all stored
when it receives a non-error response to a request with a method responses whose target URI matches the given URI, or will mark them
whose safety is unknown. as "invalid" and in need of a mandatory validation before they can be
sent in response to a subsequent request.
Here, a "non-error response" is one with a 2xx (Successful) or 3xx A "non-error response" is one with a 2xx (Successful) or 3xx
(Redirection) status code. (Redirection) status code.
Note that this does not guarantee that all appropriate responses are
invalidated globally; a state-changing request would only invalidate
responses in the caches it travels through.
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 | Ref. |
+---------------+-----------+------+
| Age | standard | 5.1 |
| Cache-Control | standard | 5.2 |
| Expires | standard | 5.3 |
| Pragma | standard | 5.4 |
| Warning | obsoleted | 5.5 |
+---------------+-----------+------+
Table 1
5.1. Age 5.1. Age
The "Age" header field conveys the sender's estimate of the time The "Age" response header field conveys the sender's estimate of the
since the response was generated or successfully validated at the time since the response was generated or successfully validated at
origin server. Age values are calculated as specified in the origin server. Age values are calculated as specified in
Section 4.2.3. Section 4.2.3.
Age = delta-seconds Age = delta-seconds
The Age field value is a non-negative integer, representing time in The Age field value is a non-negative integer, representing time in
seconds (see Section 1.3). A cache SHOULD consider a response to be seconds (see Section 1.3).
stale if an Age field is present and its value is invalid (i.e.,
contains a list or something other than a non-negative integer). Although it is defined as a singleton header field, a cache
encountering a message with multiple Age field lines SHOULD use the
first field line, discarding subsequent ones.
If the field value (after discarding additional lines, as per above)
is invalid (e.g., it contains a list or something other than a non-
negative integer), a cache SHOULD consider the response to be stale.
The presence of an Age header field implies that the response was not The presence of an Age header field implies that the response was not
generated or validated by the origin server for this request. generated or validated by the origin server for this request.
However, lack of an Age header field does not imply the origin was However, lack of an Age header field does not imply the origin was
contacted, since the response might have been received from an contacted, since the response might have been received from an
HTTP/1.0 cache that does not implement Age. HTTP/1.0 cache that does not implement Age.
5.2. Cache-Control 5.2. Cache-Control
The "Cache-Control" header field is used to list directives for The "Cache-Control" header field is used to list directives for
skipping to change at page 24, line 5 skipping to change at page 24, line 24
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 = #cache-directive Cache-Control = #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 |
+------------------+----------------------------------+
| max-age | Section 5.2.1.1, Section 5.2.2.9 |
| max-stale | Section 5.2.1.2 |
| min-fresh | Section 5.2.1.3 |
| must-revalidate | Section 5.2.2.1 |
| must-understand | Section 5.2.2.2 |
| 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-transform | Section 5.2.1.6, Section 5.2.2.5 |
| only-if-cached | Section 5.2.1.7 |
| private | Section 5.2.2.7 |
| proxy-revalidate | Section 5.2.2.8 |
| public | Section 5.2.2.6 |
| s-maxage | Section 5.2.2.10 |
+------------------+----------------------------------+
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:
delta-seconds (see Section 1.3) delta-seconds (see Section 1.3)
skipping to change at page 29, line 14 skipping to change at page 28, line 52
The unqualified "private" response directive indicates that a shared The unqualified "private" response directive indicates that a shared
cache MUST NOT store the response (i.e., the response is intended for cache MUST NOT store the response (i.e., the response is intended for
a single user). It also indicates that a private cache MAY store the a single user). It also indicates that a private cache MAY store the
response, subject the constraints defined in Section 3, even if the response, subject the constraints defined in Section 3, even if the
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 header fields are limited to a single user: a shared cache MUST NOT
the listed fields if they are present in the original response, but store the listed header fields if they are present in the original
MAY store the remainder of the response message without those fields, response, but MAY store the remainder of the response message without
subject the constraints defined in Section 3. those header 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 32, line 4 skipping to change at page 31, line 44
The "Hypertext Transfer Protocol (HTTP) Cache Directive Registry" The "Hypertext Transfer Protocol (HTTP) Cache Directive Registry"
defines the namespace for the cache directives. It has been created defines the namespace for the cache directives. It has been created
and is now maintained at <https://www.iana.org/assignments/http- and is now maintained at <https://www.iana.org/assignments/http-
cache-directives>. cache-directives>.
A registration MUST include the following fields: A registration MUST include the following fields:
o Cache Directive Name o Cache Directive Name
o Pointer to specification text o Pointer to specification text
Values to be added to this namespace require IETF Review (see Values to be added to this namespace require IETF Review (see
[RFC8126], Section 4.8). [RFC8126], Section 4.8).
5.3. Expires 5.3. Expires
The "Expires" header field gives the date/time after which the The "Expires" response header field gives the date/time after which
response is considered stale. See Section 4.2 for further discussion the response is considered stale. See Section 4.2 for further
of the freshness model. discussion of the freshness model.
The presence of an Expires field does not imply that the original The presence of an Expires header field does not imply that the
resource will change or cease to exist at, before, or after that original resource will change or cease to exist at, before, or after
time. that time.
The Expires value is an HTTP-date timestamp, as defined in The Expires field value is an HTTP-date timestamp, as defined in
Section 5.7.7 of [Semantics]. Section 5.7.7 of [Semantics].
Expires = HTTP-date Expires = HTTP-date
For example For example
Expires: Thu, 01 Dec 1994 16:00:00 GMT Expires: Thu, 01 Dec 1994 16:00:00 GMT
A cache recipient MUST interpret invalid date formats, especially the A cache recipient MUST interpret invalid date formats, especially the
value "0", as representing a time in the past (i.e., "already value "0", as representing a time in the past (i.e., "already
expired"). expired").
If a response includes a Cache-Control field with the max-age If a response includes a Cache-Control header field with the max-age
directive (Section 5.2.2.9), a recipient MUST ignore the Expires directive (Section 5.2.2.9), a recipient MUST ignore the Expires
field. Likewise, if a response includes the s-maxage directive header field. Likewise, if a response includes the s-maxage
(Section 5.2.2.10), a shared cache recipient MUST ignore the Expires directive (Section 5.2.2.10), a shared cache recipient MUST ignore
field. In both these cases, the value in Expires is only intended the Expires header field. In both these cases, the value in Expires
for recipients that have not yet implemented the Cache-Control field. is only intended for recipients that have not yet implemented the
Cache-Control header field.
An origin server without a clock MUST NOT generate an Expires field An origin server without a clock MUST NOT generate an Expires header
unless its value represents a fixed time in the past (always expired) field unless its value represents a fixed time in the past (always
or its value has been associated with the resource by a system or expired) or its value has been associated with the resource by a
user with a reliable clock. system or user with a reliable clock.
Historically, HTTP required the Expires field value to be no more Historically, HTTP required the Expires field value to be no more
than a year in the future. While longer freshness lifetimes are no than a year in the future. While longer freshness lifetimes are no
longer prohibited, extremely large values have been demonstrated to longer prohibited, extremely large values have been demonstrated to
cause problems (e.g., clock overflows due to use of 32-bit integers cause problems (e.g., clock overflows due to use of 32-bit integers
for time values), and many caches will evict a response far sooner for time values), and many caches will evict a response far sooner
than that. than that.
5.4. Pragma 5.4. Pragma
The "Pragma" header field was defined for HTTP/1.0 caches, so that The "Pragma" request header field was defined for HTTP/1.0 caches, so
clients could specify a "no-cache" request (as Cache-Control was not that clients could specify a "no-cache" request (as Cache-Control was
defined until HTTP/1.1). not 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 | *Note:* Because the meaning of "Pragma: no-cache" in responses
| was never specified, it does not provide a reliable replacement | was never specified, it does not provide a reliable replacement
| for "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.
6. Relationship to Applications 6. Relationship to Applications and Other Caches
Applications using HTTP often specify additional forms of caching. Applications using HTTP often specify additional forms of caching.
For example, Web browsers often have history mechanisms such as For example, Web browsers often have history mechanisms such as
"Back" buttons that can be used to redisplay a representation "Back" buttons that can be used to redisplay a representation
retrieved earlier in a session. retrieved earlier in a session.
Likewise, some Web browsers implement caching of images and other Likewise, some Web browsers implement caching of images and other
assets within a page view; they may or may not honor HTTP caching assets within a page view; they may or may not honor HTTP caching
semantics. semantics.
The requirements in this specification do not necessarily apply to The requirements in this specification do not necessarily apply to
how applications use data after it is retrieved from a HTTP cache. how applications use data after it is retrieved from a HTTP cache.
That is, a history mechanism can display a previous representation For example, a history mechanism can display a previous
even if it has expired, and an application can use cached data in representation even if it has expired, and an application can use
other ways beyond its freshness lifetime. cached data in other ways beyond its freshness lifetime.
This does not prohibit the application from taking HTTP caching into This specification does not prohibit the application from taking HTTP
account; for example, a history mechanism might tell the user that a caching into account; for example, a history mechanism might tell the
view is stale, or it might honor cache directives (e.g., Cache- user that a view is stale, or it might honor cache directives (e.g.,
Control: no-store). Cache-Control: no-store). In particular, when an application caches
data and does not make this apparent to or easily controllable by the
user, it is strongly encouraged to honour basic control mechanisms
like Cache-Control: no-store, as they indicate the resource's intent
regarding caching.
7. Security Considerations 7. Security Considerations
This section is meant to inform developers, information providers, This section is meant to inform developers, information providers,
and users of known security concerns specific to HTTP caching. More and users of known security concerns specific to HTTP caching. More
general security considerations are addressed in HTTP messaging general security considerations are addressed in HTTP messaging
[Messaging] and semantics [Semantics]. [Messaging] and semantics [Semantics].
Caches expose additional potential vulnerabilities, since the Caches expose additional potential vulnerabilities, since the
contents of the cache represent an attractive target for malicious contents of the cache represent an attractive target for malicious
skipping to change at page 35, line 23 skipping to change at page 35, line 16
inhibit caching; a cacheable response with a Set-Cookie header field inhibit caching; a cacheable response with a Set-Cookie header field
can be (and often is) used to satisfy subsequent requests to caches. can be (and often is) used to satisfy subsequent requests to caches.
Servers who wish to control caching of these responses are encouraged Servers who wish to control caching of these responses are encouraged
to emit appropriate Cache-Control response header fields. to emit appropriate Cache-Control response header fields.
8. IANA Considerations 8. IANA Considerations
The change controller for the following registrations is: "IETF The change controller for the following registrations is: "IETF
(iesg@ietf.org) - Internet Engineering Task Force". (iesg@ietf.org) - Internet Engineering Task Force".
8.1. Field Registration 8.1. Field Name Registration
Please update the "Hypertext Transfer Protocol (HTTP) Field Name First, introduce the new "Hypertext Transfer Protocol (HTTP) Field
Registry" at <https://www.iana.org/assignments/http-fields> with the Name Registry" at <https://www.iana.org/assignments/http-fields> as
field names listed in the two tables of Section 5. described in Section 17.4 of [Semantics].
Then, please update the registry with the field names listed in the
table below:
+---------------+-----------+------+----------+
| Field Name | Status | Ref. | Comments |
+---------------+-----------+------+----------+
| Age | standard | 5.1 | |
| Cache-Control | standard | 5.2 | |
| Expires | standard | 5.3 | |
| Pragma | standard | 5.4 | |
| Warning | obsoleted | 5.5 | |
+---------------+-----------+------+----------+
Table 1
8.2. Cache Directive Registration 8.2. Cache Directive Registration
Please update the "Hypertext Transfer Protocol (HTTP) Cache Directive Please update the "Hypertext Transfer Protocol (HTTP) Cache Directive
Registry" at <https://www.iana.org/assignments/http-cache-directives> Registry" at <https://www.iana.org/assignments/http-cache-directives>
with the registration procedure of Section 5.2.4 and the cache with the registration procedure of Section 5.2.4 and the cache
directive names summarized in the table of Section 5.2. directive names summarized in the table below.
+------------------+----------------------------------+
| Cache Directive | Reference |
+------------------+----------------------------------+
| max-age | Section 5.2.1.1, Section 5.2.2.9 |
| max-stale | Section 5.2.1.2 |
| min-fresh | Section 5.2.1.3 |
| must-revalidate | Section 5.2.2.1 |
| must-understand | Section 5.2.2.2 |
| 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-transform | Section 5.2.1.6, Section 5.2.2.5 |
| only-if-cached | Section 5.2.1.7 |
| private | Section 5.2.2.7 |
| proxy-revalidate | Section 5.2.2.8 |
| public | Section 5.2.2.6 |
| s-maxage | Section 5.2.2.10 |
+------------------+----------------------------------+
Table 2
8.3. Warn Code Registry 8.3. Warn Code Registry
Please add a note to the "Hypertext Transfer Protocol (HTTP) Warn Please add a note to the "Hypertext Transfer Protocol (HTTP) Warn
Codes" registry at <https://www.iana.org/assignments/http-warn-codes> Codes" registry at <https://www.iana.org/assignments/http-warn-codes>
to the effect that Warning is obsoleted. to the effect that Warning is obsoleted.
9. References 9. References
9.1. Normative References 9.1. Normative References
[Messaging] [Messaging]
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP/1.1 Messaging", Work in Progress, Internet- Ed., "HTTP/1.1 Messaging", Work in Progress, Internet-
Draft, draft-ietf-httpbis-messaging-latest, October 2020, Draft, draft-ietf-httpbis-messaging-latest, November 2020,
<https://tools.ietf.org/html/draft-ietf-httpbis-messaging- <https://tools.ietf.org/html/draft-ietf-httpbis-messaging-
latest>. latest>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
skipping to change at page 36, line 26 skipping to change at page 37, line 16
RFC 7405, DOI 10.17487/RFC7405, December 2014, RFC 7405, DOI 10.17487/RFC7405, December 2014,
<https://www.rfc-editor.org/info/rfc7405>. <https://www.rfc-editor.org/info/rfc7405>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[Semantics] [Semantics]
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", Work in Progress, Internet-Draft, Ed., "HTTP Semantics", Work in Progress, Internet-Draft,
draft-ietf-httpbis-semantics-latest, October 2020, draft-ietf-httpbis-semantics-latest, November 2020,
<https://tools.ietf.org/html/draft-ietf-httpbis-semantics- <https://tools.ietf.org/html/draft-ietf-httpbis-semantics-
latest>. latest>.
[USASCII] American National Standards Institute, "Coded Character
Set -- 7-bit American Standard Code for Information
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,
DOI 10.17487/RFC2616, June 1999, DOI 10.17487/RFC2616, June 1999,
<https://www.rfc-editor.org/info/rfc2616>. <https://www.rfc-editor.org/info/rfc2616>.
[RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale [RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale
Content", RFC 5861, DOI 10.17487/RFC5861, April 2010, Content", RFC 5861, DOI 10.17487/RFC5861, April 2010,
skipping to change at page 37, line 46 skipping to change at page 38, line 32
delta-seconds = 1*DIGIT delta-seconds = 1*DIGIT
field-name = <field-name, see [Semantics], Section 5.4.3> field-name = <field-name, see [Semantics], Section 5.4.3>
quoted-string = <quoted-string, see [Semantics], Section 5.7.4> quoted-string = <quoted-string, see [Semantics], Section 5.7.4>
token = <token, see [Semantics], Section 5.7.2> token = <token, see [Semantics], Section 5.7.2>
Appendix B. Changes from RFC 7234 Appendix B. Changes from RFC 7234
Handling of duplicate and conflicting cache directives has been
clarified. (Section 4.2.1)
Cache invalidation of the URIs in the Location and Content-Location
header fields is no longer required, but still allowed.
(Section 4.4)
Cache invalidation of the URIs in the Location and Content-Location
header fields is disallowed when the origin is different; previously,
it was the host. (Section 4.4)
Handling invalid and multiple Age header field values has been Handling invalid and multiple Age header field values has been
clarified. (Section 5.1) clarified. (Section 5.1)
Some cache directives defined by this specification now have stronger Some cache directives defined by this specification now have stronger
prohibitions against generating the quoted form of their values, prohibitions against generating the quoted form of their values,
since this has been found to create interoperability problems. since this has been found to create interoperability problems.
Consumers of extension cache directives are no longer required to Consumers of extension cache directives are no longer required to
accept both token and quoted-string forms, but they still need to accept both token and quoted-string forms, but they still need to
parse them properly for unknown extensions. (Section 5.2) parse them properly for unknown extensions. (Section 5.2)
The "public" and "private" cache directives were clarified, so that The "public" and "private" cache directives were clarified, so that
they do not make responses reusable under any condition. they do not make responses reusable under any condition.
(Section 5.2.2) (Section 5.2.2)
The "must-understand" cache directive was introduced; caches are no The "must-understand" cache directive was introduced; caches are no
longer required to understand the semantics of new response status longer required to understand the semantics of new response status
codes unless it is present. (Section 5.2.2.2) codes unless it is present. (Section 5.2.2.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
skipping to change at page 42, line 9 skipping to change at page 42, line 51
C.12. Since draft-ietf-httpbis-cache-10 C.12. Since draft-ietf-httpbis-cache-10
o In Section 5.2 (Cache-Control), adjust ABNF to allow empty lists o In Section 5.2 (Cache-Control), adjust ABNF to allow empty lists
(<https://github.com/httpwg/http-core/issues/210>) (<https://github.com/httpwg/http-core/issues/210>)
C.13. Since draft-ietf-httpbis-cache-11 C.13. Since draft-ietf-httpbis-cache-11
o None. o None.
C.14. Since draft-ietf-httpbis-cache-12
o In Section 4.2.4, remove 'no-store', as it won't be in cache in
the first place (<https://github.com/httpwg/http-core/issues/447>)
o In Section 3.1, make it clear that only response headers need be
stored (<https://github.com/httpwg/http-core/issues/457>)
o In Section 4.2.1 clarify how to handle invalid and conflicting
directives (<https://github.com/httpwg/http-core/issues/460>)
o In Section 4.3.3, mention retry of failed validation requests
(<https://github.com/httpwg/http-core/issues/462>)
o In Section 4.3.3, clarify requirement on storing a full response
to a conditional request (<https://github.com/httpwg/http-core/
issues/463>)
o In Section 5.1, clarify error handling
(<https://github.com/httpwg/http-core/issues/471>)
o In Section 4.2, remove spurious "UTC" (<https://github.com/httpwg/
http-core/issues/472>)
o In Section 4.2, correct the date-related rule names to consider
case-insensitive (<https://github.com/httpwg/http-core/
issues/473>)
o In Section 6, strengthen recommendation for application caches to
pay attention to cache directives (<https://github.com/httpwg/
http-core/issues/474>)
o In Section 4, mention collapsed requests
(<https://github.com/httpwg/http-core/issues/475>)
o In Section 4.4, relax requirements on Content-Location and
Location invalidation (<https://github.com/httpwg/http-core/
issues/478>)
o In Section 4.3.4, refine the exceptions to update on a 304
(<https://github.com/httpwg/http-core/issues/488>)
o Moved table of Cache-Control directives into Section 8.2
(<https://github.com/httpwg/http-core/issues/506>)
o In Section 1.2, remove unused core ABNF rules
(<https://github.com/httpwg/http-core/issues/529>)
Acknowledgments Acknowledgments
See Appendix "Acknowledgments" of [Semantics]. See Appendix "Acknowledgments" of [Semantics].
Authors' Addresses Authors' Addresses
Roy T. Fielding (editor) Roy T. Fielding (editor)
Adobe Adobe
345 Park Ave 345 Park Ave
San Jose, CA 95110 San Jose, CA 95110
 End of changes. 66 change blocks. 
200 lines changed or deleted 299 lines changed or added

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