draft-ietf-httpbis-cache-06.txt   draft-ietf-httpbis-cache-07.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: May 7, 2020 J. Reschke, Ed. Expires: September 8, 2020 J. Reschke, Ed.
greenbytes greenbytes
November 4, 2019 March 7, 2020
HTTP Caching HTTP Caching
draft-ietf-httpbis-cache-06 draft-ietf-httpbis-cache-07
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.7. The changes in this draft are summarized in Appendix C.8.
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 May 7, 2020. This Internet-Draft will expire on September 8, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 47 skipping to change at page 2, line 47
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5
1.3. Delta Seconds . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Delta Seconds . . . . . . . . . . . . . . . . . . . . . . 6
2. Overview of Cache Operation . . . . . . . . . . . . . . . . . 6 2. Overview of Cache Operation . . . . . . . . . . . . . . . . . 6
3. Storing Responses in Caches . . . . . . . . . . . . . . . . . 7 3. Storing Responses in Caches . . . . . . . . . . . . . . . . . 7
3.1. Storing Incomplete Responses . . . . . . . . . . . . . . 8 3.1. Storing Incomplete Responses . . . . . . . . . . . . . . 8
3.2. Storing Responses to Authenticated Requests . . . . . . . 9 3.2. Storing Responses to Authenticated Requests . . . . . . . 9
3.3. Combining Partial Content . . . . . . . . . . . . . . . . 9 3.3. Combining Partial Content . . . . . . . . . . . . . . . . 9
4. Constructing Responses from Caches . . . . . . . . . . . . . 9 4. Constructing Responses from Caches . . . . . . . . . . . . . 10
4.1. Calculating Cache Keys with Vary . . . . . . . . . . . . 10 4.1. Calculating Cache Keys with Vary . . . . . . . . . . . . 11
4.2. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2.1. Calculating Freshness Lifetime . . . . . . . . . . . 13 4.2.1. Calculating Freshness Lifetime . . . . . . . . . . . 13
4.2.2. Calculating Heuristic Freshness . . . . . . . . . . . 14 4.2.2. Calculating Heuristic Freshness . . . . . . . . . . . 14
4.2.3. Calculating Age . . . . . . . . . . . . . . . . . . . 14 4.2.3. Calculating Age . . . . . . . . . . . . . . . . . . . 15
4.2.4. Serving Stale Responses . . . . . . . . . . . . . . . 16 4.2.4. Serving Stale Responses . . . . . . . . . . . . . . . 16
4.3. Validation . . . . . . . . . . . . . . . . . . . . . . . 16 4.3. Validation . . . . . . . . . . . . . . . . . . . . . . . 16
4.3.1. Sending a Validation Request . . . . . . . . . . . . 16 4.3.1. Sending a Validation Request . . . . . . . . . . . . 17
4.3.2. Handling a Received Validation Request . . . . . . . 17 4.3.2. Handling a Received Validation Request . . . . . . . 17
4.3.3. Handling a Validation Response . . . . . . . . . . . 19 4.3.3. Handling a Validation Response . . . . . . . . . . . 19
4.3.4. Freshening Stored Responses upon Validation . . . . . 19 4.3.4. Freshening Stored Responses upon Validation . . . . . 19
4.3.5. Freshening Responses with HEAD . . . . . . . . . . . 20 4.3.5. Freshening Responses with HEAD . . . . . . . . . . . 20
4.4. Invalidation . . . . . . . . . . . . . . . . . . . . . . 20 4.4. Invalidation . . . . . . . . . . . . . . . . . . . . . . 21
5. Header Field Definitions . . . . . . . . . . . . . . . . . . 21 5. Field Definitions . . . . . . . . . . . . . . . . . . . . . . 21
5.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 22 5.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 22
5.2.1. Request Cache-Control Directives . . . . . . . . . . 23 5.2.1. Request Cache-Control Directives . . . . . . . . . . 23
5.2.1.1. max-age . . . . . . . . . . . . . . . . . . . . . 23 5.2.1.1. max-age . . . . . . . . . . . . . . . . . . . . . 23
5.2.1.2. max-stale . . . . . . . . . . . . . . . . . . . . 23 5.2.1.2. max-stale . . . . . . . . . . . . . . . . . . . . 24
5.2.1.3. min-fresh . . . . . . . . . . . . . . . . . . . . 24 5.2.1.3. min-fresh . . . . . . . . . . . . . . . . . . . . 24
5.2.1.4. no-cache . . . . . . . . . . . . . . . . . . . . 24 5.2.1.4. no-cache . . . . . . . . . . . . . . . . . . . . 24
5.2.1.5. no-store . . . . . . . . . . . . . . . . . . . . 24 5.2.1.5. no-store . . . . . . . . . . . . . . . . . . . . 25
5.2.1.6. no-transform . . . . . . . . . . . . . . . . . . 25 5.2.1.6. no-transform . . . . . . . . . . . . . . . . . . 25
5.2.1.7. only-if-cached . . . . . . . . . . . . . . . . . 25 5.2.1.7. only-if-cached . . . . . . . . . . . . . . . . . 25
5.2.2. Response Cache-Control Directives . . . . . . . . . . 25 5.2.2. Response Cache-Control Directives . . . . . . . . . . 25
5.2.2.1. must-revalidate . . . . . . . . . . . . . . . . . 25 5.2.2.1. must-revalidate . . . . . . . . . . . . . . . . . 25
5.2.2.2. no-cache . . . . . . . . . . . . . . . . . . . . 26 5.2.2.2. must-understand . . . . . . . . . . . . . . . . . 26
5.2.2.3. no-store . . . . . . . . . . . . . . . . . . . . 26 5.2.2.3. no-cache . . . . . . . . . . . . . . . . . . . . 26
5.2.2.4. no-transform . . . . . . . . . . . . . . . . . . 27 5.2.2.4. no-store . . . . . . . . . . . . . . . . . . . . 27
5.2.2.5. public . . . . . . . . . . . . . . . . . . . . . 27 5.2.2.5. no-transform . . . . . . . . . . . . . . . . . . 27
5.2.2.6. private . . . . . . . . . . . . . . . . . . . . . 27 5.2.2.6. public . . . . . . . . . . . . . . . . . . . . . 27
5.2.2.7. proxy-revalidate . . . . . . . . . . . . . . . . 28 5.2.2.7. private . . . . . . . . . . . . . . . . . . . . . 28
5.2.2.8. max-age . . . . . . . . . . . . . . . . . . . . . 28 5.2.2.8. proxy-revalidate . . . . . . . . . . . . . . . . 28
5.2.2.9. s-maxage . . . . . . . . . . . . . . . . . . . . 28 5.2.2.9. max-age . . . . . . . . . . . . . . . . . . . . . 29
5.2.2.10. s-maxage . . . . . . . . . . . . . . . . . . . . 29
5.2.3. Cache Control Extensions . . . . . . . . . . . . . . 29 5.2.3. Cache Control Extensions . . . . . . . . . . . . . . 29
5.2.4. Cache Directive Registry . . . . . . . . . . . . . . 30 5.2.4. Cache Directive Registry . . . . . . . . . . . . . . 30
5.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 30 5.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . 31 5.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.5. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 31 5.5. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 32
6. Relationship to Applications . . . . . . . . . . . . . . . . 31 6. Relationship to Applications . . . . . . . . . . . . . . . . 32
7. Security Considerations . . . . . . . . . . . . . . . . . . . 32 7. Security Considerations . . . . . . . . . . . . . . . . . . . 33
7.1. Cache Poisoning . . . . . . . . . . . . . . . . . . . . . 32 7.1. Cache Poisoning . . . . . . . . . . . . . . . . . . . . . 33
7.2. Timing Attacks . . . . . . . . . . . . . . . . . . . . . 32 7.2. Timing Attacks . . . . . . . . . . . . . . . . . . . . . 33
7.3. Caching of Sensitive Information . . . . . . . . . . . . 33 7.3. Caching of Sensitive Information . . . . . . . . . . . . 34
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
8.1. Header Field Registration . . . . . . . . . . . . . . . . 33 8.1. Field Registration . . . . . . . . . . . . . . . . . . . 34
8.2. Cache Directive Registration . . . . . . . . . . . . . . 33 8.2. Cache Directive Registration . . . . . . . . . . . . . . 34
8.3. Warn Code Registry . . . . . . . . . . . . . . . . . . . 33 8.3. Warn Code Registry . . . . . . . . . . . . . . . . . . . 34
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
9.1. Normative References . . . . . . . . . . . . . . . . . . 33 9.1. Normative References . . . . . . . . . . . . . . . . . . 34
9.2. Informative References . . . . . . . . . . . . . . . . . 34 9.2. Informative References . . . . . . . . . . . . . . . . . 35
Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 36
Appendix B. Changes from RFC 7234 . . . . . . . . . . . . . . . 36 Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 37
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 36 Appendix B. Changes from RFC 7234 . . . . . . . . . . . . . . . 37
C.1. Between RFC7234 and draft 00 . . . . . . . . . . . . . . 36 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 38
C.2. Since draft-ietf-httpbis-cache-00 . . . . . . . . . . . . 37 C.1. Between RFC7234 and draft 00 . . . . . . . . . . . . . . 38
C.3. Since draft-ietf-httpbis-cache-01 . . . . . . . . . . . . 37 C.2. Since draft-ietf-httpbis-cache-00 . . . . . . . . . . . . 38
C.4. Since draft-ietf-httpbis-cache-02 . . . . . . . . . . . . 37 C.3. Since draft-ietf-httpbis-cache-01 . . . . . . . . . . . . 38
C.5. Since draft-ietf-httpbis-cache-03 . . . . . . . . . . . . 38 C.4. Since draft-ietf-httpbis-cache-02 . . . . . . . . . . . . 38
C.6. Since draft-ietf-httpbis-cache-04 . . . . . . . . . . . . 38 C.5. Since draft-ietf-httpbis-cache-03 . . . . . . . . . . . . 39
C.7. Since draft-ietf-httpbis-cache-05 . . . . . . . . . . . . 38 C.6. Since draft-ietf-httpbis-cache-04 . . . . . . . . . . . . 39
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 C.7. Since draft-ietf-httpbis-cache-05 . . . . . . . . . . . . 39
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 40 C.8. Since draft-ietf-httpbis-cache-06 . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
1. Introduction 1. Introduction
The Hypertext Transfer Protocol (HTTP) is a stateless application- The Hypertext Transfer Protocol (HTTP) is a stateless application-
level request/response protocol that uses extensible semantics and level request/response protocol that uses extensible semantics and
self-descriptive messages for flexible interaction with network-based self-descriptive messages for flexible interaction with network-based
hypertext information systems. HTTP is defined by a series of hypertext information systems. HTTP is defined by a series of
documents that collectively form the HTTP/1.1 specification: documents that collectively form the HTTP/1.1 specification:
o "HTTP Semantics" [Semantics] o "HTTP Semantics" [Semantics]
skipping to change at page 5, line 18 skipping to change at page 5, line 22
not fresh, it might still be reusable if it can be freshened by not fresh, it might still be reusable if it can be freshened by
validation (Section 4.3) or if the origin is unavailable validation (Section 4.3) or if the origin is unavailable
(Section 4.2.4). (Section 4.2.4).
This document obsoletes RFC 7234, with the changes being summarized This document obsoletes RFC 7234, with the changes being summarized
in Appendix B. in Appendix B.
1.1. Requirements Notation 1.1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Conformance criteria and considerations regarding error handling are Conformance criteria and considerations regarding error handling are
defined in Section 3 of [Semantics]. defined in Section 3 of [Semantics].
1.2. Syntax Notation 1.2. Syntax Notation
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 12 of [Semantics], It also uses a list extension, defined in Section 4.5 of [Semantics],
that allows for compact definition of comma-separated lists using a that allows for compact definition of comma-separated lists using a
'#' operator (similar to how the '*' operator indicates repetition). '#' operator (similar to how the '*' operator indicates repetition).
Appendix A shows the collected grammar with all list operators Appendix A shows the collected grammar with all list operators
expanded to standard ABNF notation. expanded to standard ABNF notation.
The following core rules are included by reference, as defined in The following core rules are included by reference, as defined in
[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
(CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line 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 feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any
visible [USASCII] character). visible [USASCII] character).
The rules below are defined in [Semantics]: The rules below are defined in [Semantics]:
HTTP-date = <HTTP-date, see [Semantics], Section 10.1.1.1> HTTP-date = <HTTP-date, see [Semantics], Section 10.1.1.1>
OWS = <OWS, see [Semantics], Section 11.1> OWS = <OWS, see [Semantics], Section 1.2.1>
field-name = <field-name, see [Semantics], Section 4.1> field-name = <field-name, see [Semantics], Section 4.3>
quoted-string = <quoted-string, see [Semantics], Section 4.2.3.2> quoted-string = <quoted-string, see [Semantics], Section 4.4.1.2>
token = <token, see [Semantics], Section 4.2.3.1> token = <token, see [Semantics], Section 4.4.1.1>
1.3. Delta Seconds 1.3. Delta Seconds
The delta-seconds rule specifies a non-negative integer, representing The delta-seconds rule specifies a non-negative integer, representing
time in seconds. time in seconds.
delta-seconds = 1*DIGIT delta-seconds = 1*DIGIT
A recipient parsing a delta-seconds value and converting it to binary A recipient parsing a delta-seconds value and converting it to binary
form ought to use an arithmetic type of at least 31 bits of non- form ought to use an arithmetic type of at least 31 bits of non-
skipping to change at page 7, line 26 skipping to change at page 7, line 31
than GET if the method's definition allows such caching and defines than GET if the method's definition allows such caching and defines
something suitable for use as a cache key. something suitable for use as a cache key.
A cache is disconnected when it cannot contact the origin server or A cache is disconnected when it cannot contact the origin server or
otherwise find a forward path for a given request. A disconnected otherwise find a forward path for a given request. A disconnected
cache can serve stale responses in some circumstances cache can serve stale responses in some circumstances
(Section 4.2.4). (Section 4.2.4).
3. Storing Responses in Caches 3. Storing Responses in Caches
A cache MUST NOT store a response to any request, unless: A cache MUST NOT store a response to a request unless:
o The request method is understood by the cache, and o the request method is understood by the cache;
o the response status code is final (see Section 9.3 of o the response status code is final (see Section 9 of [Semantics]);
[Messaging]), and
o the response status code is understood by the cache, and o if the response status code is 206 or 304, or the "must-
understand" cache directive (see Section 5.2) is present: the
cache understands the response status code;
o the "no-store" cache directive (see Section 5.2) does not appear o the "no-store" cache directive is not present in the response (see
in the response, and Section 5.2);
o the "private" response directive (see Section 5.2.2.6) does not o if the cache is shared: the "private" response directive is either
appear in the response, if the cache is shared, and not present or allows a modified response to be stored by a shared
cache; see Section 5.2.2.7);
o the Authorization header field (see Section 8.5.3 of [Semantics]) o if the cache is shared: the Authorization header field is not
does not appear in the request, if the cache is shared, unless the present in the request (see Section 8.5.3 of [Semantics]) or a
response explicitly allows it (see Section 3.2), and response directive is present that explicitly allows shared
caching (see Section 3.2); and,
o the response either: o the response contains at least one of:
* contains an Expires header field (see Section 5.3), or * a public response directive (see Section 5.2.2.6);
* contains a max-age response directive (see Section 5.2.2.8), or * an Expires header field (see Section 5.3);
* contains a s-maxage response directive (see Section 5.2.2.9)
and the cache is shared, or
* contains a Cache Control Extension (see Section 5.2.3) that * a max-age response directive (see Section 5.2.2.9);
allows it to be cached, or
* has a status code that is defined as heuristically cacheable * if the cache is shared, an s-maxage response directive (see
(see Section 4.2.2), or Section 5.2.2.10);
* contains a public response directive (see Section 5.2.2.5). * a Cache Control Extension that allows it to be cached (see
Section 5.2.3); or,
* a status code that is defined as heuristically cacheable (see
Section 4.2.2).
Note that any of the requirements listed above can be overridden by a Note that any of the requirements listed above can be overridden by a
cache-control extension; see Section 5.2.3. cache-control extension; see Section 5.2.3.
In this context, a cache has "understood" a request method or a In this context, a cache has "understood" a request method or a
response status code if it recognizes it and implements all specified response status code if it recognizes it and implements all specified
caching-related behavior. caching-related behavior.
Note that, in normal operation, some caches will not store a response Note that, in normal operation, some caches will not store a response
that has neither a cache validator nor an explicit expiration time, that has neither a cache validator nor an explicit expiration time,
skipping to change at page 9, line 19 skipping to change at page 9, line 26
requests unless the response has been made complete or the request is requests unless the response has been made complete or the request is
partial and specifies a range that is wholly within the incomplete partial and specifies a range that is wholly within the incomplete
response. A cache MUST NOT send a partial response to a client response. A cache MUST NOT send a partial response to a client
without explicitly marking it as such using the 206 (Partial Content) without explicitly marking it as such using the 206 (Partial Content)
status code. status code.
3.2. Storing Responses to Authenticated Requests 3.2. Storing Responses to Authenticated Requests
A shared cache MUST NOT use a cached response to a request with an A shared cache MUST NOT use a cached response to a request with an
Authorization header field (Section 8.5.3 of [Semantics]) to satisfy Authorization header field (Section 8.5.3 of [Semantics]) to satisfy
any subsequent request unless a response directive that allows such any subsequent request unless the response contains a Cache-Control
responses to be stored is present. field with a response directive (Section 5.2.2) that allows it to be
stored by a shared cache and the cache conforms to the requirements
of that directive for that response.
In this specification, the following Cache-Control response In this specification, the following response directives have such an
directives (Section 5.2.2) have such an effect: must-revalidate, effect: must-revalidate (Section 5.2.2.1), public (Section 5.2.2.6),
public, and s-maxage. and s-maxage (Section 5.2.2.10).
3.3. Combining Partial Content 3.3. Combining Partial Content
A response might transfer only a partial representation if the A response might transfer only a partial representation if the
connection closed prematurely or if the request used one or more connection closed prematurely or if the request used one or more
Range specifiers (Section 8.3 of [Semantics]). After several such Range specifiers (Section 8.3 of [Semantics]). After several such
transfers, a cache might have received several ranges of the same transfers, a cache might have received several ranges of the same
representation. A cache MAY combine these ranges into a single representation. A cache MAY combine these ranges into a single
stored response, and reuse that response to satisfy later requests, stored response, and reuse that response to satisfy later requests,
if they all share the same strong validator and the cache complies if they all share the same strong validator and the cache complies
skipping to change at page 9, line 47 skipping to change at page 10, line 10
When combining the new response with one or more stored responses, a When combining the new response with one or more stored responses, a
cache MUST use the header fields provided in the new response, aside cache MUST use the header fields provided in the new response, aside
from Content-Range, to replace all instances of the corresponding from Content-Range, to replace all instances of the corresponding
header fields in the stored response. header fields in the stored response.
4. Constructing Responses from Caches 4. Constructing Responses from Caches
When presented with a request, a cache MUST NOT reuse a stored When presented with a request, a cache MUST NOT reuse a stored
response, unless: response, unless:
o The presented effective request URI (Section 5.3 of [Semantics]) o The presented effective request URI (Section 5.5 of [Semantics])
and that of the stored response match, and and that of the stored response match, and
o the request method associated with the stored response allows it o the request method associated with the stored response allows it
to be used for the presented request, and to be used for the presented request, and
o selecting header fields nominated by the stored response (if any) o selecting header fields nominated by the stored response (if any)
match those presented (see Section 4.1), and match those presented (see Section 4.1), and
o the stored response does not contain the no-cache cache directive o the stored response does not contain the no-cache cache directive
(Section 5.2.2.2), unless it is successfully validated (Section 5.2.2.3), unless it is successfully validated
(Section 4.3), and (Section 4.3), and
o the stored response is either: o the stored response is either:
* fresh (see Section 4.2), or * fresh (see Section 4.2), or
* allowed to be served stale (see Section 4.2.4), or * allowed to be served stale (see Section 4.2.4), or
* successfully validated (see Section 4.3). * successfully validated (see Section 4.3).
skipping to change at page 11, line 16 skipping to change at page 11, line 27
response), and the presented request. response), and the presented request.
The selecting header fields from two requests are defined to match if The selecting header fields from two requests are defined to match if
and only if those in the first request can be transformed to those in and only if those in the first request can be transformed to those in
the second request by applying any of the following: the second request by applying any of the following:
o adding or removing whitespace, where allowed in the header field's o adding or removing whitespace, where allowed in the header field's
syntax syntax
o combining multiple header fields with the same field name (see o combining multiple header fields with the same field name (see
Section 4.2 of [Semantics]) Section 4.4 of [Semantics])
o normalizing both header field values in a way that is known to o normalizing both header field values in a way that is known to
have identical semantics, according to the header field's have identical semantics, according to the header field's
specification (e.g., reordering field values when order is not specification (e.g., reordering field values when order is not
significant; case-normalization, where values are defined to be significant; case-normalization, where values are defined to be
case-insensitive) case-insensitive)
If (after any normalization that might take place) a header field is If (after any normalization that might take place) a header field is
absent from a request, it can only match another request if it is absent from a request, it can only match another request if it is
also absent there. also absent there.
A Vary header field-value of "*" always fails to match. A Vary header field value containing a member "*" always fails to
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 preferred responses; of the
remainder, the most recent response (as determined by the Date header remainder, the most recent response (as determined by the Date header
skipping to change at page 12, line 27 skipping to change at page 12, line 37
A response's age is the time that has passed since it was generated A response's age is the time that has passed since it was generated
by, or successfully validated with, the origin server. by, or successfully validated with, the origin server.
When a response is "fresh" in the cache, it can be used to satisfy When a response is "fresh" in the cache, it can be used to satisfy
subsequent requests without contacting the origin server, thereby subsequent requests without contacting the origin server, thereby
improving efficiency. improving efficiency.
The primary mechanism for determining freshness is for an origin The primary mechanism for determining freshness is for an origin
server to provide an explicit expiration time in the future, using server to provide an explicit expiration time in the future, using
either the Expires header field (Section 5.3) or the max-age response either the Expires header field (Section 5.3) or the max-age response
directive (Section 5.2.2.8). Generally, origin servers will assign directive (Section 5.2.2.9). Generally, origin servers will assign
future explicit expiration times to responses in the belief that the future explicit expiration times to responses in the belief that the
representation is not likely to change in a semantically significant representation is not likely to change in a semantically significant
way before the expiration time is reached. way before the expiration time is reached.
If an origin server wishes to force a cache to validate every If an origin server wishes to force a cache to validate every
request, it can assign an explicit expiration time in the past to request, it can assign an explicit expiration time in the past to
indicate that the response is already stale. Compliant caches will indicate that the response is already stale. Compliant caches will
normally validate a stale cached response before reusing it for normally validate a stale cached response before reusing it for
subsequent requests (see Section 4.2.4). subsequent requests (see Section 4.2.4).
skipping to change at page 13, line 34 skipping to change at page 13, line 44
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 the freshness_lifetime) of a response by using the first match of the
following: following:
o If the cache is shared and the s-maxage response directive o If the cache is shared and the s-maxage response directive
(Section 5.2.2.9) is present, use its value, or (Section 5.2.2.10) is present, use its value, or
o If the max-age response directive (Section 5.2.2.8) is present, o If the max-age response directive (Section 5.2.2.9) is present,
use its value, or use its value, or
o If the Expires response header field (Section 5.3) is present, use o If the Expires response header field (Section 5.3) is present, use
its value minus the value of the Date response header field, 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
skipping to change at page 17, line 20 skipping to change at page 17, line 29
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
field (Section 10.2.2 of [Semantics]), which can be used in an If- field (Section 10.2.2 of [Semantics]), which can be used in an If-
Modified-Since header field for response validation, or in an If- Modified-Since header field for response validation, or in an If-
Unmodified-Since or If-Range header field for representation Unmodified-Since or If-Range header field for representation
selection (i.e., the client is referring specifically to a previously selection (i.e., the client is referring specifically to a previously
obtained representation with that timestamp). obtained representation with that timestamp).
Another validator is the entity-tag given in an ETag header field Another validator is the entity-tag given in an ETag field
(Section 10.2.3 of [Semantics]). One or more entity-tags, indicating (Section 10.2.3 of [Semantics]). One or more entity-tags, indicating
one or more stored responses, can be used in an If-None-Match header one or more stored responses, can be used in an If-None-Match header
field for response validation, or in an If-Match or If-Range header field for response validation, or in an If-Match or If-Range header
field for representation selection (i.e., the client is referring field for representation selection (i.e., the client is referring
specifically to one or more previously obtained representations with specifically to one or more previously obtained representations with
the listed entity-tags). the listed entity-tags).
4.3.2. Handling a Received Validation Request 4.3.2. Handling a Received Validation Request
Each client in the request chain may have its own cache, so it is Each client in the request chain may have its own cache, so it is
skipping to change at page 18, line 8 skipping to change at page 18, line 17
The proper evaluation of conditional requests by a cache depends on The proper evaluation of conditional requests by a cache depends on
the received precondition header fields and their precedence, as the received precondition header fields and their precedence, as
defined in Section 8.2.2 of [Semantics]. The If-Match and If- defined in Section 8.2.2 of [Semantics]. The If-Match and If-
Unmodified-Since conditional header fields are not applicable to a Unmodified-Since conditional header fields are not applicable to a
cache. cache.
A request containing an If-None-Match header field (Section 8.2.4 of A request containing an If-None-Match header field (Section 8.2.4 of
[Semantics]) indicates that the client wants to validate one or more [Semantics]) indicates that the client wants to validate one or more
of its own stored responses in comparison to whichever stored of its own stored responses in comparison to whichever stored
response is selected by the cache. If the field-value is "*", or if response is selected by the cache. If the field value is "*", or if
the field-value is a list of entity-tags and at least one of them the field value is a list of entity-tags and at least one of them
matches the entity-tag of the selected stored response, a cache matches the entity-tag of the selected stored response, a cache
recipient SHOULD generate a 304 (Not Modified) response (using the recipient SHOULD generate a 304 (Not Modified) response (using the
metadata of the selected stored response) instead of sending that metadata of the selected stored response) instead of sending that
stored response. stored response.
When a cache decides to revalidate its own stored responses for a When a cache decides to revalidate its own stored responses for a
request that contains an If-None-Match list of entity-tags, the cache request that contains an If-None-Match list of entity-tags, the cache
MAY combine the received list with a list of entity-tags from its own MAY combine the received list with a list of entity-tags from its own
stored set of responses (fresh or stale) and send the union of the stored set of responses (fresh or stale) and send the union of the
two lists as a replacement If-None-Match header field value in the two lists as a replacement If-None-Match header field value in the
forwarded request. If a stored response contains only partial forwarded request. If a stored response contains only partial
content, the cache MUST NOT include its entity-tag in the union content, the cache MUST NOT include its entity-tag in the union
unless the request is for a range that would be fully satisfied by unless the request is for a range that would be fully satisfied by
that partial stored response. If the response to the forwarded that partial stored response. If the response to the forwarded
request is 304 (Not Modified) and has an ETag header field value with request is 304 (Not Modified) and has an ETag field value with an
an entity-tag that is not in the client's list, the cache MUST entity-tag that is not in the client's list, the cache MUST generate
generate a 200 (OK) response for the client by reusing its a 200 (OK) response for the client by reusing its corresponding
corresponding stored response, as updated by the 304 response stored response, as updated by the 304 response metadata
metadata (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 8.2.5 of [Semantics]) an If-Modified-Since header field (Section 8.2.5 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 field is present in the selected stored response, but it has
a Date field-value that is earlier than or equal to the conditional a Date field value that is earlier than or equal to the conditional
timestamp; or, 3) neither Last-Modified nor Date is present in the timestamp; or, 3) neither Last-Modified nor Date is present in the
selected stored response, but the cache recorded it as having been selected stored response, but the cache recorded it as having been
received at a time earlier than or equal to the conditional received at a time earlier than or equal to the conditional
timestamp. timestamp.
A cache that implements partial responses to range requests, as A cache that implements partial responses to range requests, as
defined in Section 8.3 of [Semantics], also needs to evaluate a defined in Section 8.3 of [Semantics], also needs to evaluate a
received If-Range header field (Section 8.2.7 of [Semantics]) with received If-Range header field (Section 8.2.7 of [Semantics]) with
respect to its selected stored response. respect to its selected stored response.
skipping to change at page 20, line 47 skipping to change at page 21, line 12
stored response's header section unless otherwise restricted by the stored response's header section unless otherwise restricted by the
Cache-Control header field. Cache-Control header field.
4.4. Invalidation 4.4. Invalidation
Because unsafe request methods (Section 7.2.1 of [Semantics]) such as Because unsafe request methods (Section 7.2.1 of [Semantics]) such as
PUT, POST or DELETE have the potential for changing state on the PUT, POST or DELETE have the potential for changing state on the
origin server, intervening caches can use them to keep their contents origin server, intervening caches can use them to keep their contents
up to date. up to date.
A cache MUST invalidate the effective Request URI (Section 5.3 of A cache MUST invalidate the effective Request URI (Section 5.5 of
[Semantics]) as well as the URI(s) in the Location and Content- [Semantics]) as well as the URI(s) in the Location and Content-
Location response header fields (if present) when a non-error status Location response header fields (if present) when a non-error status
code is received in response to an unsafe request method. code is received in response to an unsafe request method.
However, a cache MUST NOT invalidate a URI from a Location or However, a cache MUST NOT invalidate a URI from a Location or
Content-Location response header field if the host part of that URI Content-Location response header field if the host part of that URI
differs from the host part in the effective request URI (Section 5.3 differs from the host part in the effective request URI (Section 5.5
of [Semantics]). This helps prevent denial-of-service attacks. of [Semantics]). This helps prevent denial-of-service attacks.
A cache MUST invalidate the effective request URI (Section 5.3 of A cache MUST invalidate the effective request URI (Section 5.5 of
[Semantics]) when it receives a non-error response to a request with [Semantics]) when it receives a non-error response to a request with
a method whose safety is unknown. a method whose safety is unknown.
Here, a "non-error response" is one with a 2xx (Successful) or 3xx Here, a "non-error response" is one with a 2xx (Successful) or 3xx
(Redirection) status code. "Invalidate" means that the cache will (Redirection) status code. "Invalidate" means that the cache will
either remove all stored responses related to the effective request either remove all stored responses related to the effective request
URI or will mark these as "invalid" and in need of a mandatory URI or will mark these as "invalid" and in need of a mandatory
validation before they can be sent in response to a subsequent validation before they can be sent in response to a subsequent
request. request.
Note that this does not guarantee that all appropriate responses are Note that this does not guarantee that all appropriate responses are
invalidated. For example, a state-changing request might invalidate invalidated. For example, a state-changing request might invalidate
responses in the caches it travels through, but relevant responses responses in the caches it travels through, but relevant responses
still might be stored in other caches that it has not. still might be stored in other caches that it has not.
5. Header Field Definitions 5. Field Definitions
This section defines the syntax and semantics of HTTP header fields This section defines the syntax and semantics of HTTP fields related
related to caching. to caching.
+-------------------+-----------+--------------+ +---------------+-----------+--------------+
| Header 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
The Age field-value is a non-negative integer, representing time in The Age field value is a non-negative integer, representing time in
seconds (see Section 1.3). seconds (see Section 1.3).
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 specify 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 one define arguments, recipients ought to accept both forms, even if a
is documented to be preferred. For any directive not defined by this specific form is required for generation.
specification, a recipient MUST accept both forms.
Cache-Control = 1#cache-directive Cache-Control = 1#cache-directive
cache-directive = token [ "=" ( token / quoted-string ) ] cache-directive = token [ "=" ( token / quoted-string ) ]
For the cache directives defined below, no argument is defined (nor For the cache directives defined below, no argument is defined (nor
allowed) unless stated otherwise. allowed) unless stated otherwise.
+------------------+-----------------------------------+ +------------------+-----------------------------------+
| Cache Directive | Reference | | Cache Directive | Reference |
+------------------+-----------------------------------+ +------------------+-----------------------------------+
| max-age | Section 5.2.1.1, Section 5.2.2.8 | | 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 |
| no-cache | Section 5.2.1.4, Section 5.2.2.2 | | must-understand | Section 5.2.2.2 |
| no-store | Section 5.2.1.5, Section 5.2.2.3 | | no-cache | Section 5.2.1.4, Section 5.2.2.3 |
| no-transform | Section 5.2.1.6, 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 |
| only-if-cached | Section 5.2.1.7 | | only-if-cached | Section 5.2.1.7 |
| private | Section 5.2.2.6 | | private | Section 5.2.2.7 |
| proxy-revalidate | Section 5.2.2.7 | | proxy-revalidate | Section 5.2.2.8 |
| public | Section 5.2.2.5 | | public | Section 5.2.2.6 |
| s-maxage | Section 5.2.2.9 | | 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
skipping to change at page 23, line 41 skipping to change at page 24, line 6
Argument syntax: Argument syntax:
delta-seconds (see Section 1.3) delta-seconds (see Section 1.3)
The "max-age" request directive indicates that the client prefers a The "max-age" request directive indicates that the client prefers a
response whose age is less than or equal to the specified number of response whose age is less than or equal to the specified number of
seconds. Unless the max-stale request directive is also present, the seconds. Unless the max-stale request directive is also present, the
client does not wish to receive a stale response. client does not wish to receive a stale response.
This directive uses the token form of the argument syntax: e.g., This directive uses the token form of the argument syntax: e.g.,
'max-age=5' not 'max-age="5"'. A sender SHOULD NOT generate the 'max-age=5' not 'max-age="5"'. A sender MUST NOT generate the
quoted-string form. quoted-string form.
5.2.1.2. max-stale 5.2.1.2. max-stale
Argument syntax: Argument syntax:
delta-seconds (see Section 1.3) delta-seconds (see Section 1.3)
The "max-stale" request directive indicates that the client is The "max-stale" request directive indicates that the client is
willing to accept a response that has exceeded its freshness willing to accept a response that has exceeded its freshness
lifetime. If a value is present, then the client is willing to lifetime. If a value is present, then the client is willing to
accept a response that has exceeded its freshness lifetime by no more accept a response that has exceeded its freshness lifetime by no more
than the specified number of seconds. If no value is assigned to than the specified number of seconds. If no value is assigned to
max-stale, then the client is willing to accept a stale response of max-stale, then the client is willing to accept a stale response of
any age. any age.
This directive uses the token form of the argument syntax: e.g., This directive uses the token form of the argument syntax: e.g.,
'max-stale=10' not 'max-stale="10"'. A sender SHOULD NOT generate 'max-stale=10' not 'max-stale="10"'. A sender MUST NOT generate the
the quoted-string form. quoted-string form.
5.2.1.3. min-fresh 5.2.1.3. min-fresh
Argument syntax: Argument syntax:
delta-seconds (see Section 1.3) delta-seconds (see Section 1.3)
The "min-fresh" request directive indicates that the client prefers a The "min-fresh" request directive indicates that the client prefers a
response whose freshness lifetime is no less than its current age response whose freshness lifetime is no less than its current age
plus the specified time in seconds. That is, the client wants a plus the specified time in seconds. That is, the client wants a
response that will still be fresh for at least the specified number response that will still be fresh for at least the specified number
of seconds. of seconds.
This directive uses the token form of the argument syntax: e.g., This directive uses the token form of the argument syntax: e.g.,
'min-fresh=20' not 'min-fresh="20"'. A sender SHOULD NOT generate 'min-fresh=20' not 'min-fresh="20"'. A sender MUST NOT generate the
the quoted-string form. quoted-string form.
5.2.1.4. no-cache 5.2.1.4. no-cache
The "no-cache" request directive indicates that the client prefers The "no-cache" request directive indicates that the client prefers
stored response not be used to satisfy the request without successful stored response not be used to satisfy the request without successful
validation on the origin server. validation on the origin server.
5.2.1.5. no-store 5.2.1.5. no-store
The "no-store" request directive indicates that a cache MUST NOT The "no-store" request directive indicates that a cache MUST NOT
skipping to change at page 25, line 13 skipping to change at page 25, line 28
be vulnerable to eavesdropping. be vulnerable to eavesdropping.
Note that if a request containing this directive is satisfied from a Note that if a request containing this directive is satisfied from a
cache, the no-store request directive does not apply to the already cache, the no-store request directive does not apply to the already
stored response. stored response.
5.2.1.6. no-transform 5.2.1.6. no-transform
The "no-transform" request directive indicates that the client is The "no-transform" request directive indicates that the client is
asking for intermediares (whether or not they implement a cache) to asking for intermediares (whether or not they implement a cache) to
avoid transforming the payload, as defined in Section 5.5.2 of avoid transforming the payload, as defined in Section 5.7.2 of
[Semantics]. [Semantics].
5.2.1.7. only-if-cached 5.2.1.7. only-if-cached
The "only-if-cached" request directive indicates that the client only The "only-if-cached" request directive indicates that the client only
wishes to obtain a stored response. Caches that honor this request wishes to obtain a stored response. Caches that honor this request
directive SHOULD, upon receiving it, either respond using a stored directive SHOULD, upon receiving it, either respond using a stored
response that is consistent with the other constraints of the response that is consistent with the other constraints of the
request, or respond with a 504 (Gateway Timeout) status code. request, or respond with a 504 (Gateway Timeout) status code.
5.2.2. Response Cache-Control Directives 5.2.2. Response Cache-Control Directives
This section defines cache response directives. A cache MUST obey This section defines cache response directives. A cache MUST obey
the requirements of the Cache-Control directives defined in this the requirements of the Cache-Control directives defined in this
section. section.
5.2.2.1. must-revalidate 5.2.2.1. must-revalidate
The "must-revalidate" response directive indicates that once it has The "must-revalidate" response directive indicates that once the
become stale, the response MUST NOT be used to satisfy any other response has become stale, a cache MUST NOT reuse that response to
request without forwarding it for validation and receiving a satisfy another request until it has been successfully validated by
successful response; see Section 4.3. the origin, as defined by Section 4.3.
The must-revalidate directive is necessary to support reliable The must-revalidate directive is necessary to support reliable
operation for certain protocol features. In all circumstances a operation for certain protocol features. In all circumstances a
cache MUST obey the must-revalidate directive; in particular, if a cache MUST obey the must-revalidate directive; in particular, if a
cache is disconnected, it MUST generate a 504 (Gateway Timeout) cache is disconnected, the cache MUST generate a 504 (Gateway
response. Timeout) response rather than reuse the stale response.
The must-revalidate directive ought to be used by servers if and only The must-revalidate directive ought to be used by servers if and only
if failure to validate a request on the representation could result if failure to validate a request on the representation could result
in incorrect operation, such as a silently unexecuted financial in incorrect operation, such as a silently unexecuted financial
transaction. transaction.
The must-revalidate directive also has the effect of allowing a The must-revalidate directive also permits a shared cache to reuse a
stored response to be used to satisfy a request with an Authorization response to a request containing an Authorization header field,
header field; see Section 3.2. subject to the above requirement on revalidation (Section 3.2).
5.2.2.2. no-cache 5.2.2.2. must-understand
The "must-understand" response directive limits caching of the
response to a cache that understands and conforms to the requirements
for that response's status code. A cache MUST NOT store a response
containing the must-understand directive if the cache does not
understand the response status code.
5.2.2.3. no-cache
Argument syntax: Argument syntax:
#field-name #field-name
The "no-cache" response directive indicates that the response MUST The "no-cache" response directive, in its unqualified form (without
NOT be used to satisfy any other request without forwarding it for an argument), indicates that the response MUST NOT be used to satisfy
validation and receiving a successful response; see Section 4.3. any other request without forwarding it for validation and receiving
a successful response; see Section 4.3.
This allows an origin server to prevent a cache from using it to This allows an origin server to prevent a cache from using the
satisfy a request without contacting it, even by caches that have response to satisfy a request without contacting it, even by caches
been configured to send stale responses. that have been configured to send stale responses.
If the no-cache response directive specifies one or more field-names, The qualified form of no-cache response directive, with an argument
then a cache MAY use the response to satisfy a subsequent request, that lists one or more field names, indicates that a cache MAY use
subject to any other restrictions on caching. However, any header the response to satisfy a subsequent request, subject to any other
fields in the response that have the field-name(s) listed MUST NOT be restrictions on caching, if the listed header fields are excluded
sent in the response to a subsequent request without successful from the subsequent response or the subsequent response has been
revalidation with the origin server. This allows an origin server to successfully revalidated with the origin server (updating or removing
prevent the re-use of certain header fields in a response, while those fields). This allows an origin server to prevent the re-use of
still allowing caching of the rest of the response. certain header fields in a response, while still allowing caching of
the rest of the response.
The field-names given are not limited to the set of header fields The field names given are not limited to the set of header fields
defined by this specification. Field names are case-insensitive. defined by this specification. Field names are case-insensitive.
This directive uses the quoted-string form of the argument syntax. A This directive uses the quoted-string form of the argument syntax. A
sender SHOULD NOT generate the token form (even if quoting appears sender SHOULD NOT generate the token form (even if quoting appears
not to be needed for single-entry lists). not to be needed for single-entry lists).
Note: Although it has been back-ported to many implementations, some Note: Although it has been back-ported to many implementations, some
HTTP/1.0 caches will not recognize or obey this directive. Also, no- HTTP/1.0 caches will not recognize or obey this directive. Also, the
cache response directives with field-names are often handled by qualified form of the directive is often handled by caches as if an
caches as if an unqualified no-cache directive was received; i.e., unqualified no-cache directive was received; i.e., the special
the special handling for the qualified form is not widely handling for the qualified form is not widely implemented.
implemented.
5.2.2.3. 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-
effort attempt to remove the information from volatile storage as effort attempt to remove the information from volatile storage as
promptly as possible after forwarding it. promptly as possible after forwarding it.
This directive is NOT a reliable or sufficient mechanism for ensuring This directive is NOT a reliable or sufficient mechanism for ensuring
privacy. In particular, malicious or compromised caches might not privacy. In particular, malicious or compromised caches might not
recognize or obey this directive, and communications networks might recognize or obey this directive, and communications networks might
be vulnerable to eavesdropping. be vulnerable to eavesdropping.
5.2.2.4. no-transform 5.2.2.5. no-transform
The "no-transform" response directive indicates that an intermediary The "no-transform" response directive indicates that an intermediary
(regardless of whether it implements a cache) MUST NOT transform the (regardless of whether it implements a cache) MUST NOT transform the
payload, as defined in Section 5.5.2 of [Semantics]. payload, as defined in Section 5.7.2 of [Semantics].
5.2.2.5. public 5.2.2.6. public
The "public" response directive indicates that any cache MAY store The "public" response directive indicates that a cache MAY store the
the response, even if the response would normally be non-cacheable or response even if it would otherwise be prohibited, subject to the
cacheable only within a private cache. (See Section 3.2 for constraints of any other response directives present. In other
additional details related to the use of public in response to a words, public explicitly marks the response as cacheable. For
request containing Authorization, and Section 3 for details of how example, public permits a shared cache to reuse a response to a
public affects responses that would normally not be stored, due to request containing an Authorization header field (Section 3.2).
their status codes not being defined as heuristically cacheable; see
Section 4.2.2.)
5.2.2.6. private If no explicit freshness information is provided, the response is is
heuristically cacheable (Section 4.2.2).
5.2.2.7. private
Argument syntax: Argument syntax:
#field-name #field-name
The "private" response directive indicates that the response message The unqualified "private" response directive indicates that a shared
is intended for a single user and MUST NOT be stored by a shared cache MUST NOT store the response (i.e., the response is intended for
cache. A private cache MAY store the response and reuse it for later a single user). It also indicates that a private cache MAY store the
requests, even if the response would normally be non-cacheable. response, subject to any other cache directives present, even if the
response would not otherwise be heuristically cacheable by a private
cache.
If the private response directive specifies one or more field-names, If a qualified private response directive is present, with an
this requirement is limited to the field-values associated with the argument that lists one or more field names, then only the listed
listed response header fields. That is, a shared cache MUST NOT fields are limited to a single user: a shared cache MUST NOT store
store the specified field-names(s), whereas it MAY store the the listed fields if they are present in the original response, but
remainder of the response message. MAY store the remainder of the response message without those fields.
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, private response directives with field-names are content. Also, the qualified form of the directive is often handled
often handled by caches as if an unqualified private directive was by caches as if an unqualified private directive was received; i.e.,
received; i.e., the special handling for the qualified form is not the special handling for the qualified form is not widely
widely implemented. implemented.
5.2.2.7. proxy-revalidate 5.2.2.8. proxy-revalidate
The "proxy-revalidate" response directive has the same meaning as the The "proxy-revalidate" response directive indicates that once the
must-revalidate response directive, except that it does not apply to response has become stale, a shared cache MUST NOT reuse that
private caches. response to satisfy another request until it has been successfully
validated by the origin, as defined by Section 4.3. This is
analogous to must-revalidate (Section 5.2.2.1), except that proxy-
revalidate does not apply to private caches.
5.2.2.8. max-age Note that "proxy-revalidate" on its own does not imply that a
response is cacheable. For example, it might be combined with the
public directive (Section 5.2.2.6), allowing the response to be
cached while requiring only a shared cache to revalidate when stale.
5.2.2.9. max-age
Argument syntax: Argument syntax:
delta-seconds (see Section 1.3) delta-seconds (see Section 1.3)
The "max-age" response directive indicates that the response is to be The "max-age" response directive indicates that the response is to be
considered stale after its age is greater than the specified number considered stale after its age is greater than the specified number
of seconds. of seconds.
This directive uses the token form of the argument syntax: e.g., This directive uses the token form of the argument syntax: e.g.,
'max-age=5' not 'max-age="5"'. A sender SHOULD NOT generate the 'max-age=5' not 'max-age="5"'. A sender MUST NOT generate the
quoted-string form. quoted-string form.
5.2.2.9. s-maxage 5.2.2.10. s-maxage
Argument syntax: Argument syntax:
delta-seconds (see Section 1.3) delta-seconds (see Section 1.3)
The "s-maxage" response directive indicates that, in shared caches, The "s-maxage" response directive indicates that, for a shared cache,
the maximum age specified by this directive overrides the maximum age the maximum age specified by this directive overrides the maximum age
specified by either the max-age directive or the Expires header specified by either the max-age directive or the Expires header
field. The s-maxage directive also implies the semantics of the field.
proxy-revalidate response directive.
The must-revalidate directive also has the effect of allowing a The s-maxage directive incorporates the proxy-revalidate
stored response to be used to satisfy a request with an Authorization (Section 5.2.2.8) response directive's semantics for a shared cache.
header field; see Section 3.2. A shared cache MUST NOT reuse a stale response with s-maxage to
satisfy another request until it has been successfully validated by
the origin, as defined by Section 4.3. This directive also permits a
shared cache to reuse a response to a request containing an
Authorization header field, subject to the above requirements on
maximum age and revalidation (Section 3.2).
This directive uses the token form of the argument syntax: e.g., This directive uses the token form of the argument syntax: e.g.,
's-maxage=10' not 's-maxage="10"'. A sender SHOULD NOT generate the 's-maxage=10' not 's-maxage="10"'. A sender MUST NOT generate the
quoted-string form. quoted-string form.
5.2.3. Cache Control Extensions 5.2.3. Cache Control Extensions
The Cache-Control header field can be extended through the use of one The Cache-Control header field can be extended through the use of one
or more cache-extension tokens, each with an optional value. A cache or more cache-extension tokens, each with an optional value. A cache
MUST ignore unrecognized cache directives. MUST ignore unrecognized cache directives.
Informational extensions (those that do not require a change in cache Informational extensions (those that do not require a change in cache
behavior) can be added without changing the semantics of other behavior) can be added without changing the semantics of other
skipping to change at page 30, line 45 skipping to change at page 31, line 31
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 field with the max-age
directive (Section 5.2.2.8), 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 field. Likewise, if a response includes the s-maxage directive
(Section 5.2.2.9), a shared cache recipient MUST ignore the Expires (Section 5.2.2.10), a shared cache recipient MUST ignore the Expires
field. In both these cases, the value in Expires is only intended field. In both these cases, the value in Expires is only intended
for recipients that have not yet implemented the Cache-Control field. for recipients that have not yet implemented the Cache-Control field.
An origin server without a clock MUST NOT generate an Expires field An origin server without a clock MUST NOT generate an Expires field
unless its value represents a fixed time in the past (always expired) unless its value represents a fixed time in the past (always expired)
or its value has been associated with the resource by a system or or its value has been associated with the resource by a system or
user with a reliable clock. 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" 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
skipping to change at page 33, line 25 skipping to change at page 34, line 23
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. Header Field Registration 8.1. Field Registration
Please update the "Hypertext Transfer Protocol (HTTP) Header Field Please update the "Hypertext Transfer Protocol (HTTP) Field Name
Registry" registry at <https://www.iana.org/assignments/http-headers> Registry" at <https://www.iana.org/assignments/http-fields> with the
with the header field names listed in the two tables of Section 5. field names listed in the two tables of Section 5.
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 of Section 5.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", draft-ietf-httpbis-messaging-06 Ed., "HTTP/1.1 Messaging", draft-ietf-httpbis-messaging-07
(work in progress), November 2019. (work in progress), March 2020.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
[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,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[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
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[Semantics] [Semantics]
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", draft-ietf-httpbis-semantics-06 Ed., "HTTP Semantics", draft-ietf-httpbis-semantics-07
(work in progress), November 2019. (work in progress), March 2020.
[USASCII] American National Standards Institute, "Coded Character [USASCII] American National Standards Institute, "Coded Character
Set -- 7-bit American Standard Code for Information Set -- 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986. Interchange", ANSI X3.4, 1986.
9.2. Informative References 9.2. Informative References
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, Transfer Protocol -- HTTP/1.1", RFC 2616,
skipping to change at page 36, line 8 skipping to change at page 37, line 8
<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
In the collected ABNF below, list rules are expanded as per In the collected ABNF below, list rules are expanded as per
Section 12 of [Semantics]. Section 4.5 of [Semantics].
Age = delta-seconds Age = delta-seconds
Cache-Control = [ cache-directive ] *( OWS "," OWS [ cache-directive Cache-Control = [ cache-directive ] *( OWS "," OWS [ cache-directive
] ) ] )
Expires = HTTP-date Expires = HTTP-date
HTTP-date = <HTTP-date, see [Semantics], Section 10.1.1.1> HTTP-date = <HTTP-date, see [Semantics], Section 10.1.1.1>
OWS = <OWS, see [Semantics], Section 4.3> OWS = <OWS, see [Semantics], Section 1.2.1>
cache-directive = token [ "=" ( token / quoted-string ) ] cache-directive = token [ "=" ( token / quoted-string ) ]
delta-seconds = 1*DIGIT delta-seconds = 1*DIGIT
field-name = <field-name, see [Semantics], Section 4.2> field-name = <field-name, see [Semantics], Section 4.3>
quoted-string = <quoted-string, see [Semantics], Section 4.2.3> quoted-string = <quoted-string, see [Semantics], Section 4.4.1.2>
token = <token, see [Semantics], Section 4.2.3> token = <token, see [Semantics], Section 4.4.1.1>
Appendix B. Changes from RFC 7234 Appendix B. Changes from RFC 7234
Some cache directives defined by this specification now have stronger
prohibitions against generating the quoted form of their values,
since this has been found to create interoperability problems.
Consumers of extension cache directives are no longer required to
accept both token and quoted-string forms, but they still need to
properly parse them for unknown extensions. (Section 5.2)
The "public" and "private" cache directives were clarified, so that
they do not make responses reusable under any condition.
(Section 5.2.2)
The "must-understand" cache directive was introduced; caches are no
longer required to understand the semantics of new response status
codes unless it is present. (Section 5.2.2.2)
The Warning response header was obsoleted. Much of the information The Warning response header was obsoleted. Much of the information
supported by Warning could be gleaned by examining the response), and supported by Warning could be gleaned by examining the response), and
the remaining warn-codes -- although potentially useful -- were the remaining warn-codes -- although potentially useful -- were
entirely advisory, and in practice were not added by caches or entirely advisory, and in practice were not added by caches or
intermediaries. (Section 5.5) intermediaries. (Section 5.5)
Appendix C. Change Log Appendix C. Change Log
This section is to be removed before publishing as an RFC. This section is to be removed before publishing as an RFC.
skipping to change at page 38, line 39 skipping to change at page 40, line 5
o In Section 5.2, remove the registrations for stale-if-error and o In Section 5.2, remove the registrations for stale-if-error and
stale-while-revalidate which happened in RFC 7234 stale-while-revalidate which happened in RFC 7234
(<https://github.com/httpwg/http-core/issues/207>) (<https://github.com/httpwg/http-core/issues/207>)
C.7. Since draft-ietf-httpbis-cache-05 C.7. Since draft-ietf-httpbis-cache-05
o In Section 3.1, clarify how weakly framed content is considered o In Section 3.1, clarify how weakly framed content is considered
for purposes of completeness (<https://github.com/httpwg/http- for purposes of completeness (<https://github.com/httpwg/http-
core/issues/25>) core/issues/25>)
o Througout, describe Vary and cache key operations more clearly o Throughout, describe Vary and cache key operations more clearly
(<https://github.com/httpwg/http-core/issues/28>) (<https://github.com/httpwg/http-core/issues/28>)
o In Section 3, remove concept of "cacheable methods" in favor of o In Section 3, remove concept of "cacheable methods" in favor of
prose (<https://github.com/httpwg/http-core/issues/54>) prose (<https://github.com/httpwg/http-core/issues/54>,
<https://www.rfc-editor.org/errata/eid5300>)
o Refactored Section 7, and added a section on timing attacks o Refactored Section 7, and added a section on timing attacks
(<https://github.com/httpwg/http-core/issues/233>) (<https://github.com/httpwg/http-core/issues/233>)
o Changed "cacheable by default" to "heuristically cacheable" o Changed "cacheable by default" to "heuristically cacheable"
throughout (<https://github.com/httpwg/http-core/issues/242>) throughout (<https://github.com/httpwg/http-core/issues/242>)
C.8. Since draft-ietf-httpbis-cache-06
o In Section 3 and Section 5.2.2.2, change response cacheability to
only require understanding the response status code if the must-
understand cache directive is present (<https://github.com/httpwg/
http-core/issues/120>)
o Change requirements for handling different forms of cache
directives in Section 5.2 (<https://github.com/httpwg/http-core/
issues/128>)
o Fix typo in Section 5.2.2.10 (<https://github.com/httpwg/http-
core/issues/264>)
o In Section 5.2.2.6 and Section 5.2.2.7, clarify "private" and
"public" so that they do not override all other cache directives
(<https://github.com/httpwg/http-core/issues/268>)
o In Section 3, distinguish between private with and without
qualifying headers (<https://github.com/httpwg/http-core/
issues/270>)
o In Section 4.1, clarify that any "*" as a member of Vary will
disable caching (<https://github.com/httpwg/http-core/issues/286>)
o In Section 1.1, reference RFC 8174 as well
(<https://github.com/httpwg/http-core/issues/303>)
Index Index
A A
Age header field 21 Age header field 22
age 12 age 12
C C
Cache-Control header field 22 Cache-Control header field 22
cache 4 cache 4
cache key 6 cache key 6
E E
Expires header field 30 Expires header field 31
explicit expiration time 12 explicit expiration time 12
F F
Fields
Age 22
Cache-Control 22
Expires 31
Pragma 32
Warning 32
fresh 12 fresh 12
freshness lifetime 12 freshness lifetime 12
G G
Grammar Grammar
Age 21 Age 22
ALPHA 5 ALPHA 5
Cache-Control 22 Cache-Control 23
cache-directive 22 cache-directive 23
CR 5 CR 5
CRLF 5 CRLF 5
CTL 5 CTL 5
delta-seconds 6 delta-seconds 6
DIGIT 5 DIGIT 5
DQUOTE 5 DQUOTE 5
Expires 30 Expires 31
HEXDIG 5 HEXDIG 5
HTAB 5 HTAB 5
LF 5 LF 5
OCTET 5 OCTET 5
SP 5 SP 5
VCHAR 5 VCHAR 5
H H
Header Fields
Age 22
Cache-Control 22
Expires 31
Pragma 32
Warning 32
heuristic expiration time 12 heuristic expiration time 12
heuristically cacheable 14 heuristically cacheable 14
M M
max-age (cache directive) 23, 28 max-age (cache directive) 23, 29
max-stale (cache directive) 23 max-stale (cache directive) 24
min-fresh (cache directive) 24 min-fresh (cache directive) 24
must-revalidate (cache directive) 25 must-revalidate (cache directive) 25
must-understand (cache directive) 26
N N
no-cache (cache directive) 24, 26 no-cache (cache directive) 24, 26
no-store (cache directive) 24, 26 no-store (cache directive) 25, 27
no-transform (cache directive) 25, 27 no-transform (cache directive) 25, 27
O O
only-if-cached (cache directive) 25 only-if-cached (cache directive) 25
P P
Pragma header field 31 Pragma header field 32
private (cache directive) 27 private (cache directive) 28
private cache 4 private cache 4
proxy-revalidate (cache directive) 28 proxy-revalidate (cache directive) 28
public (cache directive) 27 public (cache directive) 27
S S
s-maxage (cache directive) 28 s-maxage (cache directive) 29
shared cache 4 shared cache 4
stale 12 stale 12
strong validator 19 strong validator 19
V V
validator 16 validator 17
W W
Warning header field 31 Warning header field 32
Acknowledgments Acknowledgments
See Appendix "Acknowledgments" of [Semantics]. See Appendix "Acknowledgments" of [Semantics].
Authors' Addresses Authors' Addresses
Roy T. Fielding (editor) Roy T. Fielding (editor)
Adobe Adobe
345 Park Ave 345 Park Ave
 End of changes. 119 change blocks. 
239 lines changed or deleted 336 lines changed or added

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