draft-ietf-httpbis-cache-15.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: October 1, 2021 J. Reschke, Ed. Expires: November 7, 2021 J. Reschke, Ed.
greenbytes greenbytes
March 30, 2021 May 6, 2021
HTTP Caching HTTP Caching
draft-ietf-httpbis-cache-15 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.16. The changes in this draft are summarized in Appendix C.17.
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 October 1, 2021. This Internet-Draft will expire on November 7, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 49 skipping to change at page 2, line 49
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5
1.3. Delta Seconds . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Delta Seconds . . . . . . . . . . . . . . . . . . . . . . 6
2. Overview of Cache Operation . . . . . . . . . . . . . . . . . 6 2. Overview of Cache Operation . . . . . . . . . . . . . . . . . 6
3. Storing Responses in Caches . . . . . . . . . . . . . . . . . 7 3. Storing Responses in Caches . . . . . . . . . . . . . . . . . 7
3.1. Storing Header and Trailer Fields . . . . . . . . . . . . 8 3.1. Storing Header and Trailer Fields . . . . . . . . . . . . 8
3.2. Updating Stored Header Fields . . . . . . . . . . . . . . 9 3.2. Updating Stored Header Fields . . . . . . . . . . . . . . 9
3.3. Storing Incomplete Responses . . . . . . . . . . . . . . 10 3.3. Storing Incomplete Responses . . . . . . . . . . . . . . 10
3.4. Combining Partial Content . . . . . . . . . . . . . . . . 10 3.4. Combining Partial Content . . . . . . . . . . . . . . . . 11
3.5. Storing Responses to Authenticated Requests . . . . . . . 11 3.5. Storing Responses to Authenticated Requests . . . . . . . 11
4. Constructing Responses from Caches . . . . . . . . . . . . . 11 4. Constructing Responses from Caches . . . . . . . . . . . . . 11
4.1. Calculating Cache Keys with Vary . . . . . . . . . . . . 12 4.1. Calculating Cache Keys with Vary . . . . . . . . . . . . 12
4.2. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.1. Calculating Freshness Lifetime . . . . . . . . . . . 15 4.2.1. Calculating Freshness Lifetime . . . . . . . . . . . 15
4.2.2. Calculating Heuristic Freshness . . . . . . . . . . . 16 4.2.2. Calculating Heuristic Freshness . . . . . . . . . . . 16
4.2.3. Calculating Age . . . . . . . . . . . . . . . . . . . 16 4.2.3. Calculating Age . . . . . . . . . . . . . . . . . . . 17
4.2.4. Serving Stale Responses . . . . . . . . . . . . . . . 18 4.2.4. Serving Stale Responses . . . . . . . . . . . . . . . 18
4.3. Validation . . . . . . . . . . . . . . . . . . . . . . . 18 4.3. Validation . . . . . . . . . . . . . . . . . . . . . . . 18
4.3.1. Sending a Validation Request . . . . . . . . . . . . 18 4.3.1. Sending a Validation Request . . . . . . . . . . . . 19
4.3.2. Handling a Received Validation Request . . . . . . . 19 4.3.2. Handling a Received Validation Request . . . . . . . 19
4.3.3. Handling a Validation Response . . . . . . . . . . . 20 4.3.3. Handling a Validation Response . . . . . . . . . . . 21
4.3.4. Freshening Stored Responses upon Validation . . . . . 21 4.3.4. Freshening Stored Responses upon Validation . . . . . 21
4.3.5. Freshening Responses with HEAD . . . . . . . . . . . 21 4.3.5. Freshening Responses with HEAD . . . . . . . . . . . 22
4.4. Invalidating Stored Responses . . . . . . . . . . . . . . 22 4.4. Invalidating Stored Responses . . . . . . . . . . . . . . 22
5. Field Definitions . . . . . . . . . . . . . . . . . . . . . . 23 5. Field Definitions . . . . . . . . . . . . . . . . . . . . . . 23
5.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 5.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 23 5.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 24
5.2.1. Request Cache-Control Directives . . . . . . . . . . 24 5.2.1. Request Cache-Control Directives . . . . . . . . . . 24
5.2.1.1. max-age . . . . . . . . . . . . . . . . . . . . . 24 5.2.1.1. max-age . . . . . . . . . . . . . . . . . . . . . 24
5.2.1.2. max-stale . . . . . . . . . . . . . . . . . . . . 24 5.2.1.2. max-stale . . . . . . . . . . . . . . . . . . . . 25
5.2.1.3. min-fresh . . . . . . . . . . . . . . . . . . . . 25 5.2.1.3. min-fresh . . . . . . . . . . . . . . . . . . . . 25
5.2.1.4. no-cache . . . . . . . . . . . . . . . . . . . . 25 5.2.1.4. no-cache . . . . . . . . . . . . . . . . . . . . 25
5.2.1.5. no-store . . . . . . . . . . . . . . . . . . . . 25 5.2.1.5. no-store . . . . . . . . . . . . . . . . . . . . 26
5.2.1.6. no-transform . . . . . . . . . . . . . . . . . . 26 5.2.1.6. no-transform . . . . . . . . . . . . . . . . . . 26
5.2.1.7. only-if-cached . . . . . . . . . . . . . . . . . 26 5.2.1.7. only-if-cached . . . . . . . . . . . . . . . . . 26
5.2.2. Response Cache-Control Directives . . . . . . . . . . 26 5.2.2. Response Cache-Control Directives . . . . . . . . . . 26
5.2.2.1. max-age . . . . . . . . . . . . . . . . . . . . . 26 5.2.2.1. max-age . . . . . . . . . . . . . . . . . . . . . 26
5.2.2.2. must-revalidate . . . . . . . . . . . . . . . . . 26 5.2.2.2. must-revalidate . . . . . . . . . . . . . . . . . 27
5.2.2.3. must-understand . . . . . . . . . . . . . . . . . 27 5.2.2.3. must-understand . . . . . . . . . . . . . . . . . 27
5.2.2.4. no-cache . . . . . . . . . . . . . . . . . . . . 27 5.2.2.4. no-cache . . . . . . . . . . . . . . . . . . . . 27
5.2.2.5. no-store . . . . . . . . . . . . . . . . . . . . 28 5.2.2.5. no-store . . . . . . . . . . . . . . . . . . . . 28
5.2.2.6. no-transform . . . . . . . . . . . . . . . . . . 28 5.2.2.6. no-transform . . . . . . . . . . . . . . . . . . 29
5.2.2.7. private . . . . . . . . . . . . . . . . . . . . . 28 5.2.2.7. private . . . . . . . . . . . . . . . . . . . . . 29
5.2.2.8. proxy-revalidate . . . . . . . . . . . . . . . . 29 5.2.2.8. proxy-revalidate . . . . . . . . . . . . . . . . 30
5.2.2.9. public . . . . . . . . . . . . . . . . . . . . . 29 5.2.2.9. public . . . . . . . . . . . . . . . . . . . . . 30
5.2.2.10. s-maxage . . . . . . . . . . . . . . . . . . . . 30 5.2.2.10. s-maxage . . . . . . . . . . . . . . . . . . . . 30
5.2.3. Cache Control Extensions . . . . . . . . . . . . . . 30 5.2.3. Cache Control Extensions . . . . . . . . . . . . . . 31
5.2.4. Cache Directive Registry . . . . . . . . . . . . . . 31 5.2.4. Cache Directive Registry . . . . . . . . . . . . . . 32
5.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 31 5.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . 32 5.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.5. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 33 5.5. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 33
6. Relationship to Applications and Other Caches . . . . . . . . 33 6. Relationship to Applications and Other Caches . . . . . . . . 33
7. Security Considerations . . . . . . . . . . . . . . . . . . . 34 7. Security Considerations . . . . . . . . . . . . . . . . . . . 34
7.1. Cache Poisoning . . . . . . . . . . . . . . . . . . . . . 34 7.1. Cache Poisoning . . . . . . . . . . . . . . . . . . . . . 35
7.2. Timing Attacks . . . . . . . . . . . . . . . . . . . . . 34 7.2. Timing Attacks . . . . . . . . . . . . . . . . . . . . . 35
7.3. Caching of Sensitive Information . . . . . . . . . . . . 35 7.3. Caching of Sensitive Information . . . . . . . . . . . . 35
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
8.1. Field Name Registration . . . . . . . . . . . . . . . . . 35 8.1. Field Name Registration . . . . . . . . . . . . . . . . . 36
8.2. Cache Directive Registration . . . . . . . . . . . . . . 35 8.2. Cache Directive Registration . . . . . . . . . . . . . . 36
8.3. Warn Code Registry . . . . . . . . . . . . . . . . . . . 36 8.3. Warn Code Registry . . . . . . . . . . . . . . . . . . . 37
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
9.1. Normative References . . . . . . . . . . . . . . . . . . 36 9.1. Normative References . . . . . . . . . . . . . . . . . . 37
9.2. Informative References . . . . . . . . . . . . . . . . . 37 9.2. Informative References . . . . . . . . . . . . . . . . . 37
Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 38 Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 38
Appendix B. Changes from RFC 7234 . . . . . . . . . . . . . . . 38 Appendix B. Changes from RFC 7234 . . . . . . . . . . . . . . . 39
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 39 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 40
C.1. Between RFC7234 and draft 00 . . . . . . . . . . . . . . 39 C.1. Between RFC7234 and draft 00 . . . . . . . . . . . . . . 40
C.2. Since draft-ietf-httpbis-cache-00 . . . . . . . . . . . . 39 C.2. Since draft-ietf-httpbis-cache-00 . . . . . . . . . . . . 40
C.3. Since draft-ietf-httpbis-cache-01 . . . . . . . . . . . . 40 C.3. Since draft-ietf-httpbis-cache-01 . . . . . . . . . . . . 40
C.4. Since draft-ietf-httpbis-cache-02 . . . . . . . . . . . . 40 C.4. Since draft-ietf-httpbis-cache-02 . . . . . . . . . . . . 41
C.5. Since draft-ietf-httpbis-cache-03 . . . . . . . . . . . . 40 C.5. Since draft-ietf-httpbis-cache-03 . . . . . . . . . . . . 41
C.6. Since draft-ietf-httpbis-cache-04 . . . . . . . . . . . . 41 C.6. Since draft-ietf-httpbis-cache-04 . . . . . . . . . . . . 41
C.7. Since draft-ietf-httpbis-cache-05 . . . . . . . . . . . . 41 C.7. Since draft-ietf-httpbis-cache-05 . . . . . . . . . . . . 42
C.8. Since draft-ietf-httpbis-cache-06 . . . . . . . . . . . . 41 C.8. Since draft-ietf-httpbis-cache-06 . . . . . . . . . . . . 42
C.9. Since draft-ietf-httpbis-cache-07 . . . . . . . . . . . . 42 C.9. Since draft-ietf-httpbis-cache-07 . . . . . . . . . . . . 43
C.10. Since draft-ietf-httpbis-cache-08 . . . . . . . . . . . . 42 C.10. Since draft-ietf-httpbis-cache-08 . . . . . . . . . . . . 43
C.11. Since draft-ietf-httpbis-cache-09 . . . . . . . . . . . . 42 C.11. Since draft-ietf-httpbis-cache-09 . . . . . . . . . . . . 43
C.12. Since draft-ietf-httpbis-cache-10 . . . . . . . . . . . . 42 C.12. Since draft-ietf-httpbis-cache-10 . . . . . . . . . . . . 43
C.13. Since draft-ietf-httpbis-cache-11 . . . . . . . . . . . . 42 C.13. Since draft-ietf-httpbis-cache-11 . . . . . . . . . . . . 43
C.14. Since draft-ietf-httpbis-cache-12 . . . . . . . . . . . . 42 C.14. Since draft-ietf-httpbis-cache-12 . . . . . . . . . . . . 43
C.15. Since draft-ietf-httpbis-cache-13 . . . . . . . . . . . . 44 C.15. Since draft-ietf-httpbis-cache-13 . . . . . . . . . . . . 45
C.16. Since draft-ietf-httpbis-cache-14 . . . . . . . . . . . . 44 C.16. Since draft-ietf-httpbis-cache-14 . . . . . . . . . . . . 45
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 45 C.17. Since draft-ietf-httpbis-cache-15 . . . . . . . . . . . . 46
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48
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. It is typically used for distributed hypertext information systems. It is typically used for distributed
information systems, where the use of response caches can improve information systems, where the use of response caches can improve
performance. This document defines aspects of HTTP related to performance. This document defines aspects of HTTP related to
caching and reusing response messages. caching and reusing response messages.
skipping to change at page 18, line 45 skipping to change at page 19, line 15
4.3.1. Sending a Validation Request 4.3.1. Sending a Validation Request
When generating a conditional request for validation, a cache starts When generating a conditional request for validation, a cache starts
with either a request it is attempting to satisfy, or - if it is with either a request it is attempting to satisfy, or - if it is
initiating the request independently - it synthesises a request using initiating the request independently - it synthesises a request using
a stored response by copying the method, target URI, and request a stored response by copying the method, target URI, and request
header fields identified by the Vary header field (Section 4.1). header fields identified by the Vary header field (Section 4.1).
It then updates that request with one or more precondition header It then updates that request with one or more precondition header
fields. These contain validator metadata sourced from stored fields. These contain validator metadata sourced from stored
response(s) that have the same cache key. response(s) that have the same URI. Typically, this will include
only those stored responses(s) that have the same cache key, although
a cache is allowed to validate a response that it cannot select with
the request header fields it is sending.
The precondition header fields are then compared by recipients to The precondition header fields are then compared by recipients to
determine whether any stored response is equivalent to a current determine whether any stored response is equivalent to a current
representation of the resource. representation of the resource.
One such validator is the timestamp given in a Last-Modified header One such validator is the timestamp given in a Last-Modified header
field (Section 8.8.2 of [Semantics]), which can be used in an If- field (Section 8.8.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
skipping to change at page 19, line 29 skipping to change at page 19, line 48
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
common for a cache at an intermediary to receive conditional requests common for a cache at an intermediary to receive conditional requests
from other (outbound) caches. Likewise, some user agents make use of from other (outbound) caches. Likewise, some user agents make use of
conditional requests to limit data transfers to recently modified conditional requests to limit data transfers to recently modified
representations or to complete the transfer of a partially retrieved representations or to complete the transfer of a partially retrieved
representation. representation.
If a cache receives a request that can be satisfied by reusing one of If a cache receives a request that can be satisfied by reusing a
its stored 200 (OK) or 206 (Partial Content) responses, the cache stored 200 (OK) or 206 (Partial Content) response, as per Section 4,
SHOULD evaluate any applicable conditional header field preconditions the cache SHOULD evaluate any applicable conditional header field
received in that request with respect to the corresponding validators preconditions received in that request with respect to the
contained within the selected response. A cache MUST NOT evaluate corresponding validators contained within the selected response.
conditional header fields that only apply to an origin server, occur
in a request with semantics that cannot be satisfied with a cached A cache MUST NOT evaluate conditional header fields that only apply
response, or occur in a request with a target resource for which it to an origin server, occur in a request with semantics that cannot be
has no stored responses; such preconditions are likely intended for satisfied with a cached response, or occur in a request with a target
some other (inbound) server. resource for which it has no stored responses; such preconditions are
likely intended for some other (inbound) server.
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. In the received precondition header fields and their precedence. In
summary, the If-Match and If-Unmodified-Since conditional header summary, the If-Match and If-Unmodified-Since conditional header
fields are not applicable to a cache, and If-None-Match takes fields are not applicable to a cache, and If-None-Match takes
precedence over If-Modified-Since. See Section 13.2.2 of [Semantics] precedence over If-Modified-Since. See Section 13.2.2 of [Semantics]
for a complete specification of precondition precedence. for a complete specification of precondition precedence.
A request containing an If-None-Match header field (Section 13.1.2 of A request containing an If-None-Match header field (Section 13.1.2 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 the stored response
response is selected by the cache. selected by the cache (as per Section 4).
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
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
two lists as a replacement If-None-Match header field value in the
forwarded request. If a stored response contains only partial
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
that partial stored response. If the response to the forwarded
request is 304 (Not Modified) and has an ETag field value with an
entity-tag that is not in the client's list, the cache MUST generate
a 200 (OK) response for the client by reusing its corresponding
stored response, as updated by the 304 response metadata
(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 13.1.3 of [Semantics]) an If-Modified-Since header field (Section 13.1.3 of [Semantics])
indicates that the client wants to validate one or more of its own indicates that the client wants to validate one or more of its own
stored responses by modification date. stored responses by modification date.
If a request contains an If-Modified-Since header field and the Last- If a request contains an If-Modified-Since header field and the Last-
Modified header field is not present in a selected stored response, a Modified header field is not present in a selected stored response, a
cache SHOULD use the stored response's Date field value (or, if no cache SHOULD use the stored response's Date field value (or, if no
Date field is present, the time that the stored response was Date field is present, the time that the stored response was
received) to evaluate the conditional. received) to evaluate the conditional.
A cache that implements partial responses to range requests, as A cache that implements partial responses to range requests, as
defined in Section 14.2 of [Semantics], also needs to evaluate a defined in Section 14.2 of [Semantics], also needs to evaluate a
received If-Range header field (Section 13.1.5 of [Semantics]) received If-Range header field (Section 13.1.5 of [Semantics])
regarding its selected stored response. regarding its selected stored response.
When a cache decides to forward a request to revalidate its own
stored responses for a 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 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 forwarded request. If a stored response contains
only partial 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 that partial stored response. If the response to the
forwarded request is 304 (Not Modified) and has an ETag field value
with an entity-tag that is not in the client's list, the cache MUST
generate a 200 (OK) response for the client by reusing its
corresponding stored response, as updated by the 304 response
metadata (Section 4.3.4).
4.3.3. Handling a Validation Response 4.3.3. Handling a Validation Response
Cache handling of a response to a conditional request depends upon Cache handling of a response to a conditional request depends upon
its status code: its status code:
o A 304 (Not Modified) response status code indicates that the o A 304 (Not Modified) response status code indicates that the
stored response can be updated and reused; see Section 4.3.4. stored response can be updated and reused; see Section 4.3.4.
o A full response (i.e., one containing content) indicates that none o A full response (i.e., one containing content) indicates that none
of the stored responses nominated in the conditional request is of the stored responses nominated in the conditional request is
skipping to change at page 21, line 11 skipping to change at page 21, line 29
o However, if a cache receives a 5xx (Server Error) response while o However, if a cache receives a 5xx (Server Error) response while
attempting to validate a response, it can either forward this attempting to validate a response, it can either forward this
response to the requesting client, or act as if the server failed response to the requesting client, or act as if the server failed
to respond. In the latter case, the cache can send a previously to respond. In the latter case, the cache can send a previously
stored response, subject to its constraints on doing so (see stored response, subject to its constraints on doing so (see
Section 4.2.4), or retry the validation request. Section 4.2.4), or retry the validation request.
4.3.4. Freshening Stored Responses upon Validation 4.3.4. Freshening Stored Responses upon Validation
When a cache receives a 304 (Not Modified) response and already has When a cache receives a 304 (Not Modified) response and already has
one or more stored 200 (OK) responses for the applicable cache key, one or more stored 200 (OK) responses for the applicable request URI,
the cache needs to identify which (if any) are to be updated by the the cache needs to identify which (if any) are to be updated by the
new information provided, and then do so. new information provided, and then do so.
The stored response(s) to update are identified by using the first The stored response(s) to update are identified by using the first
match (if any) of: match (if any) of:
o If the new response contains one or more _strong validators_ (see o If the new response contains one or more _strong validators_ (see
Section 8.8.1 of [Semantics]), then each of those strong Section 8.8.1 of [Semantics]), then each of those strong
validators identify the selected representation for update. All validators identify the selected representation for update. All
the stored responses with one of those same strong validators are the stored responses with one of those same strong validators are
skipping to change at page 36, line 38 skipping to change at page 37, line 18
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", Work in Progress, Internet-Draft, draft- Ed., "HTTP/1.1", Work in Progress, Internet-Draft, draft-
ietf-httpbis-messaging-latest, March 2021, ietf-httpbis-messaging-latest, May 2021,
<https://tools.ietf.org/html/draft-ietf-httpbis-messaging- <https://tools.ietf.org/html/draft-ietf-httpbis-messaging-
latest>. latest>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
skipping to change at page 37, line 16 skipping to change at page 37, line 43
RFC 7405, DOI 10.17487/RFC7405, December 2014, RFC 7405, DOI 10.17487/RFC7405, December 2014,
<https://www.rfc-editor.org/info/rfc7405>. <https://www.rfc-editor.org/info/rfc7405>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[Semantics] [Semantics]
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", Work in Progress, Internet-Draft, Ed., "HTTP Semantics", Work in Progress, Internet-Draft,
draft-ietf-httpbis-semantics-latest, March 2021, draft-ietf-httpbis-semantics-latest, May 2021,
<https://tools.ietf.org/html/draft-ietf-httpbis-semantics- <https://tools.ietf.org/html/draft-ietf-httpbis-semantics-
latest>. latest>.
9.2. Informative References 9.2. Informative References
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, Transfer Protocol -- HTTP/1.1", RFC 2616,
DOI 10.17487/RFC2616, June 1999, DOI 10.17487/RFC2616, June 1999,
<https://www.rfc-editor.org/info/rfc2616>. <https://www.rfc-editor.org/info/rfc2616>.
skipping to change at page 43, line 4 skipping to change at page 43, line 45
C.12. Since draft-ietf-httpbis-cache-10 C.12. Since draft-ietf-httpbis-cache-10
o In Section 5.2 (Cache-Control), adjust ABNF to allow empty lists o In Section 5.2 (Cache-Control), adjust ABNF to allow empty lists
(<https://github.com/httpwg/http-core/issues/210>) (<https://github.com/httpwg/http-core/issues/210>)
C.13. Since draft-ietf-httpbis-cache-11 C.13. Since draft-ietf-httpbis-cache-11
o None. o None.
C.14. Since draft-ietf-httpbis-cache-12 C.14. Since draft-ietf-httpbis-cache-12
o In Section 4.2.4, remove 'no-store', as it won't be in cache in o In Section 4.2.4, remove 'no-store', as it won't be in cache in
the first place (<https://github.com/httpwg/http-core/issues/447>) the first place (<https://github.com/httpwg/http-core/issues/447>,
<https://www.rfc-editor.org/errata/eid6279>)
o In Section 3.1, make it clear that only response headers need be o In Section 3.1, make it clear that only response headers need be
stored (<https://github.com/httpwg/http-core/issues/457>) stored (<https://github.com/httpwg/http-core/issues/457>)
o Rewrote "Updating Stored Header Fields" Section 3.2 o Rewrote "Updating Stored Header Fields" Section 3.2
(<https://github.com/httpwg/http-core/issues/458>) (<https://github.com/httpwg/http-core/issues/458>)
o In Section 4.2.1 clarify how to handle invalid and conflicting o In Section 4.2.1 clarify how to handle invalid and conflicting
directives (<https://github.com/httpwg/http-core/issues/460>) directives (<https://github.com/httpwg/http-core/issues/460>)
skipping to change at page 45, line 5 skipping to change at page 46, line 5
o In Section 7.1, cache poisoning can affect private caches too o In Section 7.1, cache poisoning can affect private caches too
(<https://github.com/httpwg/http-core/issues/730>) (<https://github.com/httpwg/http-core/issues/730>)
o In Section 5.1, adjust handling of invalid values to match most o In Section 5.1, adjust handling of invalid values to match most
deployed caches (<https://github.com/httpwg/http-core/issues/778>) deployed caches (<https://github.com/httpwg/http-core/issues/778>)
o In Section 5.3, mention parsing requirement relaxation o In Section 5.3, mention parsing requirement relaxation
(<https://github.com/httpwg/http-core/issues/779>) (<https://github.com/httpwg/http-core/issues/779>)
C.17. Since draft-ietf-httpbis-cache-15
o In Section 4.3.1, tune description of relation between cache keys
and validators (<https://github.com/httpwg/http-core/issues/832>)
Acknowledgments Acknowledgments
See Appendix "Acknowledgments" of [Semantics]. See Appendix "Acknowledgments" of [Semantics].
Index Index
A C E F G H M N O P S V W A C E F G H M N O P S V W
A A
 End of changes. 33 change blocks. 
81 lines changed or deleted 93 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/