draft-ietf-httpbis-cache-03.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 21, 2019 J. Reschke, Ed. Expires: June 7, 2019 J. Reschke, Ed.
greenbytes greenbytes
October 18, 2018 December 4, 2018
HTTP Caching HTTP Caching
draft-ietf-httpbis-cache-03 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.4. The changes in this draft are summarized in Appendix C.5.
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 21, 2019. This Internet-Draft will expire on June 7, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 41 skipping to change at page 2, line 41
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 . . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . 8 3.2. Storing Responses to Authenticated Requests . . . . . . . 9
3.3. Combining Partial Content . . . . . . . . . . . . . . . . 8 3.3. Combining Partial Content . . . . . . . . . . . . . . . . 9
4. Constructing Responses from Caches . . . . . . . . . . . . . 9 4. Constructing Responses from Caches . . . . . . . . . . . . . 9
4.1. Calculating Secondary Keys with Vary . . . . . . . . . . 10 4.1. Calculating Secondary Keys with Vary . . . . . . . . . . 10
4.2. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2.1. Calculating Freshness Lifetime . . . . . . . . . . . 12 4.2.1. Calculating Freshness Lifetime . . . . . . . . . . . 13
4.2.2. Calculating Heuristic Freshness . . . . . . . . . . . 13 4.2.2. Calculating Heuristic Freshness . . . . . . . . . . . 13
4.2.3. Calculating Age . . . . . . . . . . . . . . . . . . . 14 4.2.3. Calculating Age . . . . . . . . . . . . . . . . . . . 14
4.2.4. Serving Stale Responses . . . . . . . . . . . . . . . 15 4.2.4. Serving Stale Responses . . . . . . . . . . . . . . . 15
4.3. Validation . . . . . . . . . . . . . . . . . . . . . . . 15 4.3. Validation . . . . . . . . . . . . . . . . . . . . . . . 16
4.3.1. Sending a Validation Request . . . . . . . . . . . . 16 4.3.1. Sending a Validation Request . . . . . . . . . . . . 16
4.3.2. Handling a Received Validation Request . . . . . . . 16 4.3.2. Handling a Received Validation Request . . . . . . . 17
4.3.3. Handling a Validation Response . . . . . . . . . . . 18 4.3.3. Handling a Validation Response . . . . . . . . . . . 18
4.3.4. Freshening Stored Responses upon Validation . . . . . 18 4.3.4. Freshening Stored Responses upon Validation . . . . . 18
4.3.5. Freshening Responses with HEAD . . . . . . . . . . . 19 4.3.5. Freshening Responses with HEAD . . . . . . . . . . . 19
4.4. Invalidation . . . . . . . . . . . . . . . . . . . . . . 20 4.4. Invalidation . . . . . . . . . . . . . . . . . . . . . . 20
5. Header Field Definitions . . . . . . . . . . . . . . . . . . 20 5. Header Field Definitions . . . . . . . . . . . . . . . . . . 20
5.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 21 5.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 21
5.2.1. Request Cache-Control Directives . . . . . . . . . . 22 5.2.1. Request Cache-Control Directives . . . . . . . . . . 22
5.2.1.1. max-age . . . . . . . . . . . . . . . . . . . . . 22 5.2.1.1. max-age . . . . . . . . . . . . . . . . . . . . . 22
5.2.1.2. max-stale . . . . . . . . . . . . . . . . . . . . 22 5.2.1.2. max-stale . . . . . . . . . . . . . . . . . . . . 23
5.2.1.3. min-fresh . . . . . . . . . . . . . . . . . . . . 23 5.2.1.3. min-fresh . . . . . . . . . . . . . . . . . . . . 23
5.2.1.4. no-cache . . . . . . . . . . . . . . . . . . . . 23 5.2.1.4. no-cache . . . . . . . . . . . . . . . . . . . . 23
5.2.1.5. no-store . . . . . . . . . . . . . . . . . . . . 23 5.2.1.5. no-store . . . . . . . . . . . . . . . . . . . . 24
5.2.1.6. no-transform . . . . . . . . . . . . . . . . . . 24 5.2.1.6. no-transform . . . . . . . . . . . . . . . . . . 24
5.2.1.7. only-if-cached . . . . . . . . . . . . . . . . . 24 5.2.1.7. only-if-cached . . . . . . . . . . . . . . . . . 24
5.2.2. Response Cache-Control Directives . . . . . . . . . . 24 5.2.2. Response Cache-Control Directives . . . . . . . . . . 24
5.2.2.1. must-revalidate . . . . . . . . . . . . . . . . . 24 5.2.2.1. must-revalidate . . . . . . . . . . . . . . . . . 24
5.2.2.2. no-cache . . . . . . . . . . . . . . . . . . . . 24 5.2.2.2. no-cache . . . . . . . . . . . . . . . . . . . . 25
5.2.2.3. no-store . . . . . . . . . . . . . . . . . . . . 25 5.2.2.3. no-store . . . . . . . . . . . . . . . . . . . . 26
5.2.2.4. no-transform . . . . . . . . . . . . . . . . . . 26 5.2.2.4. no-transform . . . . . . . . . . . . . . . . . . 26
5.2.2.5. public . . . . . . . . . . . . . . . . . . . . . 26 5.2.2.5. public . . . . . . . . . . . . . . . . . . . . . 26
5.2.2.6. private . . . . . . . . . . . . . . . . . . . . . 26 5.2.2.6. private . . . . . . . . . . . . . . . . . . . . . 26
5.2.2.7. proxy-revalidate . . . . . . . . . . . . . . . . 27 5.2.2.7. proxy-revalidate . . . . . . . . . . . . . . . . 27
5.2.2.8. max-age . . . . . . . . . . . . . . . . . . . . . 27 5.2.2.8. max-age . . . . . . . . . . . . . . . . . . . . . 27
5.2.2.9. s-maxage . . . . . . . . . . . . . . . . . . . . 27 5.2.2.9. s-maxage . . . . . . . . . . . . . . . . . . . . 27
5.2.3. Cache Control Extensions . . . . . . . . . . . . . . 27 5.2.3. Cache Control Extensions . . . . . . . . . . . . . . 28
5.2.4. Cache Directive Registry . . . . . . . . . . . . . . 28 5.2.4. Cache Directive Registry . . . . . . . . . . . . . . 29
5.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 29 5.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . 30 5.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.5. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 30 5.5. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 30
6. Relationship to Applications . . . . . . . . . . . . . . . . 31 6. Relationship to Applications . . . . . . . . . . . . . . . . 30
7. Security Considerations . . . . . . . . . . . . . . . . . . . 31 7. Security Considerations . . . . . . . . . . . . . . . . . . . 31
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
8.1. Header Field Registration . . . . . . . . . . . . . . . . 32 8.1. Header Field Registration . . . . . . . . . . . . . . . . 32
8.2. Cache Directive Registration . . . . . . . . . . . . . . 32 8.2. Cache Directive Registration . . . . . . . . . . . . . . 32
8.3. Warn Code Registry . . . . . . . . . . . . . . . . . . . 32 8.3. Warn Code Registry . . . . . . . . . . . . . . . . . . . 32
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
9.1. Normative References . . . . . . . . . . . . . . . . . . 32 9.1. Normative References . . . . . . . . . . . . . . . . . . 32
9.2. Informative References . . . . . . . . . . . . . . . . . 33 9.2. Informative References . . . . . . . . . . . . . . . . . 33
Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 35 Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 35
Appendix B. Changes from RFC 7234 . . . . . . . . . . . . . . . 35 Appendix B. Changes from RFC 7234 . . . . . . . . . . . . . . . 35
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 36 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 35
C.1. Between RFC7234 and draft 00 . . . . . . . . . . . . . . 36 C.1. Between RFC7234 and draft 00 . . . . . . . . . . . . . . 36
C.2. Since draft-ietf-httpbis-cache-00 . . . . . . . . . . . . 36 C.2. Since draft-ietf-httpbis-cache-00 . . . . . . . . . . . . 36
C.3. Since draft-ietf-httpbis-cache-01 . . . . . . . . . . . . 36 C.3. Since draft-ietf-httpbis-cache-01 . . . . . . . . . . . . 36
C.4. Since draft-ietf-httpbis-cache-02 . . . . . . . . . . . . 36 C.4. Since draft-ietf-httpbis-cache-02 . . . . . . . . . . . . 36
C.5. Since draft-ietf-httpbis-cache-03 . . . . . . . . . . . . 37
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 39 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
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
skipping to change at page 5, line 22 skipping to change at page 5, line 22
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", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
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] with a list extension, defined in Section 11 of notation of [RFC5234], extended with the notation for case-
[Semantics], that allows for compact definition of comma-separated sensitivity in strings defined in [RFC7405].
lists using a '#' operator (similar to how the '*' operator indicates
repetition). Appendix A shows the collected grammar with all list It also uses a list extension, defined in Section 11 of [Semantics],
operators expanded to standard ABNF notation. that allows for compact definition of comma-separated lists using a
'#' operator (similar to how the '*' operator indicates repetition).
Appendix A shows the collected grammar with all list operators
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]:
skipping to change at page 7, line 7 skipping to change at page 7, line 15
The primary cache key consists of the request method and target URI. The primary cache key consists of the request method and target URI.
However, since HTTP caches in common use today are typically limited However, since HTTP caches in common use today are typically limited
to caching responses to GET, many caches simply decline other methods to caching responses to GET, many caches simply decline other methods
and use only the URI as the primary cache key. and use only the URI as the primary cache key.
If a request target is subject to content negotiation, its cache If a request target is subject to content negotiation, its cache
entry might consist of multiple stored responses, each differentiated entry might consist of multiple stored responses, each differentiated
by a secondary key for the values of the original request's selecting by a secondary key for the values of the original request's selecting
header fields (Section 4.1). header fields (Section 4.1).
A cache is disconnected when it cannot contact the origin server or
otherwise find a forward path for a given request. A disconnected
cache can serve stale responses in some circumstances
(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 any request, unless:
o The request method is understood by the cache and defined as being o The request method is understood by the cache and defined as being
cacheable, and cacheable, and
o the response status code is final (see Section 9.3 of o the response status code is final (see Section 9.3 of
[Messaging]), and [Messaging]), and
o the response status code is understood by the cache, and o the response status code is understood by the cache, and
o the "no-store" cache directive (see Section 5.2) does not appear o the "no-store" cache directive (see Section 5.2) does not appear
in request or response header fields, and in the response, and
o the "private" response directive (see Section 5.2.2.6) does not o the "private" response directive (see Section 5.2.2.6) does not
appear in the response, if the cache is shared, and appear in the response, if the cache is shared, and
o the Authorization header field (see Section 8.5.3 of [Semantics]) o the Authorization header field (see Section 8.5.3 of [Semantics])
does not appear in the request, if the cache is shared, unless the does not appear in the request, if the cache is shared, unless the
response explicitly allows it (see Section 3.2), and response explicitly allows it (see Section 3.2), and
o the response either: o the response either:
skipping to change at page 8, line 38 skipping to change at page 9, line 9
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 cache directive that allows such any subsequent request unless a response directive that allows such
responses to be stored is present in the response. responses to be stored is present.
In this specification, the following Cache-Control response In this specification, the following Cache-Control response
directives (Section 5.2.2) have such an effect: must-revalidate, directives (Section 5.2.2) have such an effect: must-revalidate,
public, and s-maxage. public, and s-maxage.
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
skipping to change at page 9, line 26 skipping to change at page 9, line 46
o The presented effective request URI (Section 5.3 of [Semantics]) o The presented effective request URI (Section 5.3 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 presented request does not contain the no-cache pragma
(Section 5.4), nor the no-cache cache directive (Section 5.2.1),
unless the stored response is successfully validated
(Section 4.3), 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.2), 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
skipping to change at page 10, line 14 skipping to change at page 10, line 28
A cache MUST write through requests with methods that are unsafe A cache MUST write through requests with methods that are unsafe
(Section 7.2.1 of [Semantics]) to the origin server; i.e., a cache is (Section 7.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.
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 response (as determined by the Date header field). It most recent one (as determined by the Date header field). It can
can also forward the request with "Cache-Control: max-age=0" or also forward the request with "Cache-Control: max-age=0" or "Cache-
"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 Secondary Keys with Vary 4.1. Calculating Secondary Keys with Vary
When a cache receives a request that can be satisfied by a stored When a cache receives a request that can be satisfied by a stored
response that has a Vary header field (Section 10.1.4 of response that has a Vary header field (Section 10.1.4 of
[Semantics]), it MUST NOT use that response unless all of the [Semantics]), it MUST NOT use that response unless all of the
selecting header fields nominated by the Vary header field match in selecting header fields nominated by the Vary header field match in
skipping to change at page 12, line 16 skipping to change at page 12, line 30
caches are also allowed to use a heuristic to determine an expiration caches are also allowed to use a heuristic to determine an expiration
time under certain circumstances (see Section 4.2.2). time under certain circumstances (see Section 4.2.2).
The calculation to determine if a response is fresh is: The calculation to determine if a response is fresh is:
response_is_fresh = (freshness_lifetime > current_age) response_is_fresh = (freshness_lifetime > current_age)
freshness_lifetime is defined in Section 4.2.1; current_age is freshness_lifetime is defined in Section 4.2.1; current_age is
defined in Section 4.2.3. defined in Section 4.2.3.
Clients can send the max-age or min-fresh cache directives in a Clients can send the max-age or min-fresh request directives
request to constrain or relax freshness calculations for the (Section 5.2.1) to constrain or relax freshness calculations for the
corresponding response (Section 5.2.1). corresponding response. However, caches are not required to honor
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 day, week, and time-zone names 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
skipping to change at page 15, line 38 skipping to change at page 16, line 5
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-store" or "no-cache"
cache directive, a "must-revalidate" cache-response-directive, or an cache 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 send stale responses unless it is disconnected A cache MUST NOT send stale responses unless it is disconnected or
(i.e., it cannot contact the origin server or otherwise find a doing so is explicitly allowed (e.g., by the max-stale request
forward path) or doing so is explicitly allowed (e.g., by the max- directive; see Section 5.2.1).
stale request directive; see Section 5.2.1).
4.3. Validation 4.3. Validation
When a cache has one or more stored responses for a requested URI, When a cache has one or more stored responses for a requested URI,
but cannot serve any of them (e.g., because they are not fresh, or but cannot serve any of them (e.g., because they are not fresh, or
one cannot be selected; see Section 4.1), it can use the conditional one cannot be selected; see Section 4.1), it can use the conditional
request mechanism Section 8.2 of [Semantics] in the forwarded request request mechanism Section 8.2 of [Semantics] in the forwarded request
to give the next inbound server an opportunity to select a valid to give the next inbound server an opportunity to select a valid
stored response to use, updating the stored metadata in the process, stored response to use, updating the stored metadata in the process,
or to replace the stored response(s) with a new response. This or to replace the stored response(s) with a new response. This
skipping to change at page 20, line 43 skipping to change at page 21, line 5
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. Header Field Definitions
This section defines the syntax and semantics of HTTP header fields This section defines the syntax and semantics of HTTP header fields
related to caching. related to caching.
+-------------------+----------+-----------+--------------+ +-------------------+-----------+--------------+
| Header Field Name | Protocol | Status | Reference | | Header Field Name | Status | Reference |
+-------------------+----------+-----------+--------------+ +-------------------+-----------+--------------+
| Age | http | standard | Section 5.1 | | Age | standard | Section 5.1 |
| Cache-Control | http | standard | Section 5.2 | | Cache-Control | standard | Section 5.2 |
| Expires | http | standard | Section 5.3 | | Expires | standard | Section 5.3 |
| Pragma | http | standard | Section 5.4 | | Pragma | standard | Section 5.4 |
| Warning | http | obsoleted | Section 5.5 | | Warning | obsoleted | Section 5.5 |
+-------------------+----------+-----------+--------------+ +-------------------+-----------+--------------+
5.1. Age 5.1. Age
The "Age" header field conveys the sender's estimate of the amount of The "Age" header field conveys the sender's estimate of the amount of
time since the response was generated or successfully validated at time since the response was generated or successfully validated at
the origin server. Age values are calculated as specified in the origin server. Age values are calculated as specified in
Section 4.2.3. Section 4.2.3.
Age = delta-seconds Age = delta-seconds
skipping to change at page 21, line 31 skipping to change at page 21, line 41
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 specify 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.
A cache MUST obey the requirements of the Cache-Control directives See Section 5.2.3 for information about how Cache-Control directives
defined in this section. See Section 5.2.3 for information about how defined elsewhere are handled.
Cache-Control directives 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-
skipping to change at page 22, line 29 skipping to change at page 22, line 40
| private | Section 5.2.2.6 | | private | Section 5.2.2.6 |
| proxy-revalidate | Section 5.2.2.7 | | proxy-revalidate | Section 5.2.2.7 |
| public | Section 5.2.2.5 | | public | Section 5.2.2.5 |
| s-maxage | Section 5.2.2.9 | | s-maxage | Section 5.2.2.9 |
| stale-if-error | [RFC5861], Section 4 | | stale-if-error | [RFC5861], Section 4 |
| stale-while-revalidate | [RFC5861], Section 3 | | stale-while-revalidate | [RFC5861], Section 3 |
+------------------------+-----------------------------------+ +------------------------+-----------------------------------+
5.2.1. Request Cache-Control Directives 5.2.1. Request Cache-Control Directives
This section defines cache request directives. They are advisory;
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)
The "max-age" request directive indicates that the client is The "max-age" request directive indicates that the client prefers a
unwilling to accept a response whose age is greater than the response whose age is less than or equal to the specified number of
specified number of seconds. Unless the max-stale request directive seconds. Unless the max-stale request directive is also present, the
is also present, the client is not willing to accept a stale client does not wish to receive a stale response.
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 SHOULD 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 max-stale is assigned a value, then the client is lifetime. If a value is present, then the client is willing to
willing to accept a response that has exceeded its freshness lifetime accept a response that has exceeded its freshness lifetime by no more
by no more than the specified number of seconds. If no value is than the specified number of seconds. If no value is assigned to
assigned to max-stale, then the client is willing to accept a stale max-stale, then the client is willing to accept a stale response of
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 SHOULD NOT generate
the quoted-string form. the 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 is The "min-fresh" request directive indicates that the client prefers a
willing to accept a response whose freshness lifetime is no less than response whose freshness lifetime is no less than its current age
its current age plus the specified time in seconds. That is, the plus the specified time in seconds. That is, the client wants a
client wants a response that will still be fresh for at least the response that will still be fresh for at least the specified number
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 SHOULD NOT generate
the quoted-string form. the quoted-string form.
5.2.1.4. no-cache 5.2.1.4. no-cache
The "no-cache" request directive indicates that a cache MUST NOT use The "no-cache" request directive indicates that the client prefers
a stored response 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
store any part of either this request or any response to it. This store any part of either this request or any response to it. This
directive applies to both private and shared caches. "MUST NOT 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
skipping to change at page 24, line 11 skipping to change at page 24, line 26
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.
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 an intermediary The "no-transform" request directive indicates that the client is
(whether or not it implements a cache) MUST NOT transform the asking for intermediares (whether or not they implement a cache) to
payload, as defined in Section 5.5.2 of [Semantics]. avoid transforming the payload, as defined in Section 5.5.2 of
[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. If it receives this directive, a wishes to obtain a stored response. Caches that honor this request
cache SHOULD either respond using a stored response that is directive SHOULD, upon receiving it, either respond using a stored
consistent with the other constraints of the request, or respond with response that is consistent with the other constraints of the
a 504 (Gateway Timeout) status code. If a group of caches is being request, or respond with a 504 (Gateway Timeout) status code.
operated as a unified system with good internal connectivity, a
member cache MAY forward such a request within that group of caches.
5.2.2. Response Cache-Control Directives 5.2.2. Response Cache-Control Directives
This section defines cache response directives. A cache MUST obey
the requirements of the Cache-Control directives defined in this
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 it has
become stale, the response MUST NOT be used to satisfy any other become stale, the response MUST NOT be used to satisfy any other
request without forwarding it for validation and receiving a request without forwarding it for validation and receiving a
successful response; see Section 4.3. successful response; see 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 cannot reach the origin server for any reason, it MUST generate cache is disconnected, it MUST generate a 504 (Gateway Timeout)
a 504 (Gateway Timeout) response. 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
stored response to be used to satisfy a request with an Authorization
header field; see Section 3.2.
5.2.2.2. no-cache 5.2.2.2. 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 indicates that the response MUST
NOT be used to satisfy any other request without forwarding it for NOT be used to satisfy any other request without forwarding it for
validation and receiving a successful response; see Section 4.3. validation and receiving a successful response; see Section 4.3.
skipping to change at page 27, line 37 skipping to change at page 28, line 8
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, in shared caches,
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. The s-maxage directive also implies the semantics of the
proxy-revalidate response directive. proxy-revalidate response directive.
The must-revalidate directive also has the effect of allowing a
stored response to be used to satisfy a request with an Authorization
header field; see 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 SHOULD NOT generate the
quoted-string form. quoted-string form.
5.2.3. Cache Control Extensions 5.2.3. Cache Control Extensions
The Cache-Control header field can be extended through the use of one The Cache-Control header field can be extended through the use of one
or more cache-extension tokens, each with an optional value. A cache or more cache-extension tokens, each with an optional value. A cache
MUST ignore unrecognized cache directives. MUST ignore unrecognized cache directives.
skipping to change at page 30, line 7 skipping to change at page 30, line 26
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 allows backwards compatibility with The "Pragma" header field was defined for HTTP/1.0 caches, so that
HTTP/1.0 caches, so that clients can specify a "no-cache" request clients could specify a "no-cache" request (as Cache-Control was not
that they will understand (as Cache-Control was not defined until defined until HTTP/1.1).
HTTP/1.1). When the Cache-Control header field is also present and
understood in a request, Pragma is ignored.
In HTTP/1.0, Pragma was defined as an extensible field for
implementation-specified directives for recipients. This
specification deprecates such extensions to improve interoperability.
Pragma = 1#pragma-directive
pragma-directive = "no-cache" / extension-pragma
extension-pragma = token [ "=" ( token / quoted-string ) ]
When the Cache-Control header field is not present in a request,
caches MUST consider the no-cache request pragma-directive as having
the same effect as if "Cache-Control: no-cache" were present (see
Section 5.2.1).
When sending a no-cache request, a client ought to include both the
pragma and cache-control directives, unless Cache-Control: no-cache
is purposefully omitted to target other Cache-Control request
directives at HTTP/1.1 or greater caches. For example:
GET / HTTP/1.1
Host: www.example.com
Cache-Control: max-age=30
Pragma: no-cache
will constrain HTTP/1.1 and greater caches to serve a response no However, support for Cache-Control is now widespread. As a result,
older than 30 seconds, while precluding implementations that do not this specification deprecates Pragma.
understand Cache-Control from serving a cached response.
Note: Because the meaning of "Pragma: no-cache" in responses is Note: Because the meaning of "Pragma: no-cache" in responses was
not specified, it does not provide a reliable replacement for never specified, it does not provide a reliable replacement for
"Cache-Control: no-cache" in them. "Cache-Control: no-cache" in them.
5.5. Warning 5.5. Warning
The "Warning" header field was used to carry additional information The "Warning" header field was used to carry additional information
about the status or transformation of a message that might not be about the status or transformation of a message that might not be
reflected in the status code. This specification obsoletes it, as it reflected in the status code. This specification obsoletes it, as it
is not widely generated or surfaced to users. The information it is not widely generated or surfaced to users. The information it
carried can be gleaned from examining other header fields, such as carried can be gleaned from examining other header fields, such as
Age. Age.
skipping to change at page 32, line 26 skipping to change at page 32, line 20
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. Header Field Registration
Please update the "Message Headers" registry of "Permanent Message Please update the "Hypertext Transfer Protocol (HTTP) Header Field
Header Field Names" at <https://www.iana.org/assignments/message- Registry" registry at <https://www.iana.org/assignments/http-headers>
headers> with the header field names listed in the table of with the header field names listed in the two tables of Section 5.
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-03 Ed., "HTTP/1.1 Messaging", draft-ietf-httpbis-messaging-
(work in progress), October 2018. latest (work in progress), December 2018.
[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",
RFC 7405, DOI 10.17487/RFC7405, December 2014,
<https://www.rfc-editor.org/info/rfc7405>.
[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-03 Ed., "HTTP Semantics", draft-ietf-httpbis-semantics-latest
(work in progress), October 2018. (work in progress), December 2018.
[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 35, line 21 skipping to change at page 35, line 21
Cache-Control = *( "," OWS ) cache-directive *( OWS "," [ OWS Cache-Control = *( "," OWS ) cache-directive *( OWS "," [ OWS
cache-directive ] ) 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 4.3>
Pragma = *( "," OWS ) pragma-directive *( OWS "," [ OWS
pragma-directive ] )
cache-directive = token [ "=" ( token / quoted-string ) ] cache-directive = token [ "=" ( token / quoted-string ) ]
delta-seconds = 1*DIGIT delta-seconds = 1*DIGIT
extension-pragma = token [ "=" ( token / quoted-string ) ]
field-name = <field-name, see [Semantics], Section 4.2> field-name = <field-name, see [Semantics], Section 4.2>
port = <port, see [RFC3986], Section 3.2.3> port = <port, see [RFC3986], Section 3.2.3>
pragma-directive = "no-cache" / extension-pragma
pseudonym = <pseudonym, see [Semantics], Section 5.5.1> pseudonym = <pseudonym, see [Semantics], Section 5.5.1>
quoted-string = <quoted-string, see [Semantics], Section 4.2.3> quoted-string = <quoted-string, see [Semantics], Section 4.2.3>
token = <token, see [Semantics], Section 4.2.3> token = <token, see [Semantics], Section 4.2.3>
uri-host = <host, see [RFC3986], Section 3.2.2> uri-host = <host, see [RFC3986], Section 3.2.2>
Appendix B. Changes from RFC 7234 Appendix B. Changes from RFC 7234
skipping to change at page 37, line 20 skipping to change at page 37, line 17
o Revise Section 6 to apply to more than just History Lists o Revise Section 6 to apply to more than just History Lists
(<https://github.com/httpwg/http-core/issues/126>) (<https://github.com/httpwg/http-core/issues/126>)
o In Section 5.5, deprecated "Warning" header field o In Section 5.5, deprecated "Warning" header field
(<https://github.com/httpwg/http-core/issues/139>) (<https://github.com/httpwg/http-core/issues/139>)
o In Section 3.2, remove a spurious note o In Section 3.2, remove a spurious note
(<https://github.com/httpwg/http-core/issues/141>) (<https://github.com/httpwg/http-core/issues/141>)
C.5. Since draft-ietf-httpbis-cache-03
o In Section 2, define what a disconnected cache is
(<https://github.com/httpwg/http-core/issues/5>)
o In Section 4, clarify language around how to select a response
when more than one matches (<https://github.com/httpwg/http-core/
issues/23>)
o Remove requirements around cache request directives
(<https://github.com/httpwg/http-core/issues/129>)
o Deprecate Pragma (<https://github.com/httpwg/http-core/
issues/140>)
o In Section 3.2 and Section 5.2.2, note effect of some directives
on authenticated requests (<https://github.com/httpwg/http-core/
issues/161>)
Index Index
A A
Age header field 21 Age header field 21
age 11 age 11
C C
Cache-Control header field 21 Cache-Control header field 21
cache 4 cache 4
cache entry 6 cache entry 6
cache key 6 cache key 6-7
E E
Expires header field 29 Expires header field 29
explicit expiration time 11 explicit expiration time 11
F F
fresh 11 fresh 11
freshness lifetime 11 freshness lifetime 11
G G
Grammar Grammar
Age 21 Age 21
ALPHA 5 ALPHA 5
Cache-Control 21 Cache-Control 22
cache-directive 21 cache-directive 22
CR 5 CR 5
CRLF 5 CRLF 5
CTL 5 CTL 5
delta-seconds 5 delta-seconds 6
DIGIT 5 DIGIT 5
DQUOTE 5 DQUOTE 5
Expires 29 Expires 29
extension-pragma 30
HEXDIG 5 HEXDIG 5
HTAB 5 HTAB 5
LF 5 LF 5
OCTET 5 OCTET 5
Pragma 30
pragma-directive 30
SP 5 SP 5
VCHAR 5 VCHAR 5
H H
heuristic expiration time 11 heuristic expiration time 11
M M
max-age (cache directive) 22, 27 max-age (cache directive) 22, 27
max-stale (cache directive) 22 max-stale (cache directive) 23
min-fresh (cache directive) 23 min-fresh (cache directive) 23
must-revalidate (cache directive) 24 must-revalidate (cache directive) 24
N N
no-cache (cache directive) 23-24 no-cache (cache directive) 23, 25
no-store (cache directive) 23, 25 no-store (cache directive) 24, 26
no-transform (cache directive) 24, 26 no-transform (cache directive) 24, 26
O O
only-if-cached (cache directive) 24 only-if-cached (cache directive) 24
P P
Pragma header field 30 Pragma header field 30
private (cache directive) 26 private (cache directive) 26
private cache 4 private cache 4
proxy-revalidate (cache directive) 27 proxy-revalidate (cache directive) 27
public (cache directive) 26 public (cache directive) 26
S S
s-maxage (cache directive) 27 s-maxage (cache directive) 27
shared cache 4 shared cache 4
stale 11 stale 11
strong validator 18 strong validator 19
V V
validator 16 validator 16
W W
Warning header field 30 Warning header field 30
Acknowledgments Acknowledgments
See Appendix "Acknowledgments" of [Semantics]. See Appendix "Acknowledgments" of [Semantics].
 End of changes. 57 change blocks. 
140 lines changed or deleted 143 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/