draft-ietf-httpbis-cache-header-04.txt   draft-ietf-httpbis-cache-header-05.txt 
HTTP M. Nottingham HTTP M. Nottingham
Internet-Draft Fastly Internet-Draft Fastly
Intended status: Standards Track August 5, 2020 Intended status: Standards Track August 11, 2020
Expires: February 6, 2021 Expires: February 12, 2021
The Cache-Status HTTP Response Header Field The Cache-Status HTTP Response Header Field
draft-ietf-httpbis-cache-header-04 draft-ietf-httpbis-cache-header-05
Abstract Abstract
To aid debugging, HTTP caches often append header fields to a To aid debugging, HTTP caches often append header fields to a
response explaining how they handled the request. This specification response explaining how they handled the request. This specification
codifies that practice and updates it to align with HTTP's current codifies that practice and updates it to align with HTTP's current
caching model. caching model.
Note to Readers Note to Readers
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 February 6, 2021. This Internet-Draft will expire on February 12, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/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 3, line 32 skipping to change at page 3, line 32
Cache-Status = sf-list Cache-Status = sf-list
Each member of the list represents a cache that has handled the Each member of the list represents a cache that has handled the
request. The first member of the list represents the cache closest request. The first member of the list represents the cache closest
to the origin server, and the last member of the list represents the to the origin server, and the last member of the list represents the
cache closest to the client (possibly including the user agent's cache closest to the client (possibly including the user agent's
cache itself, if it chooses to append a value). cache itself, if it chooses to append a value).
Caches determine when it is appropriate to add the Cache-Status Caches determine when it is appropriate to add the Cache-Status
header field to a response. Some might decide to add it to all header field to a response. Some might add it to all responses,
responses, whereas others might only do so when specifically whereas others might only do so when specifically configured to, or
configured to, or when the request contains a header that activates a when the request contains a header that activates a debugging mode.
debugging mode.
When adding a value to the Cache-Status header field, caches SHOULD When adding a value to the Cache-Status header field, caches SHOULD
preserve the existing contents of the header field, to allow preserve the existing contents of the header field, to allow
debugging of the entire chain of caches handling the request. debugging of the entire chain of caches handling the request.
Each list member identifies the cache that inserted that value, and Each list member identifies the cache that inserted that value, and
MUST be a String or Token. Depending on the deployment, this might MUST be a String or Token. Depending on the deployment, this might
be a product or service name (e.g., ExampleCache or "Example CDN"), a be a product or service name (e.g., ExampleCache or "Example CDN"), a
hostname ("cache-3.example.com"), and IP address, or a generated hostname ("cache-3.example.com"), and IP address, or a generated
string. string.
skipping to change at page 4, line 17 skipping to change at page 4, line 17
fwd-status = sf-integer fwd-status = sf-integer
ttl = sf-integer ttl = sf-integer
stored = sf-boolean stored = sf-boolean
collapsed = sf-boolean collapsed = sf-boolean
key = sf-string key = sf-string
detail = sf-token / sf-string detail = sf-token / sf-string
2.1. The hit parameter 2.1. The hit parameter
"hit", when true, indicates that the request was satisfied by the "hit", when true, indicates that the request was satisfied by the
cache; i.e., it did not go forward and the response was obtained from cache; i.e., it did not go forward, and the response was obtained
the cache. A response that originally was produced by the origin but from the cache. A response that originally was produced by the
was modified by the cache (for example, a 304 or 206 status code) is origin but was modified by the cache (for example, a 304 or 206
still considered a hit. status code) is still considered a hit.
"hit" and "fwd" are exclusive; only one of them should appear on each "hit" and "fwd" are exclusive; only one of them should appear on each
list member. list member.
2.2. The fwd parameter 2.2. The fwd parameter
"fwd" indicates that the request went forward towards the origin, and "fwd" indicates that the request went forward towards the origin, and
why. why.
The following values are defined to explain why the request went The following values are defined to explain why the request went
skipping to change at page 5, line 14 skipping to change at page 5, line 14
2.3. The fwd-status parameter 2.3. The fwd-status parameter
"fwd-status" indicates what status code the next hop server returned "fwd-status" indicates what status code the next hop server returned
in response to the request. Only meaningful when "fwd" is present; in response to the request. Only meaningful when "fwd" is present;
if "fwd-status" is not present but "fwd" is, it defaults to the if "fwd-status" is not present but "fwd" is, it defaults to the
status code sent in the response. status code sent in the response.
This parameter is useful to distinguish cases when the next hop This parameter is useful to distinguish cases when the next hop
server sends a 304 Not Modified response to a conditional request, or server sends a 304 Not Modified response to a conditional request, or
a 206 Partial Response due to a range request. a 206 Partial Response because of a range request.
2.4. The ttl parameter 2.4. The ttl parameter
"ttl" indicates the response's remaining freshness lifetime as "ttl" indicates the response's remaining freshness lifetime as
calculated by the cache, as an integer number of seconds, measured calculated by the cache, as an integer number of seconds, measured
when the response is sent by the cache. This includes freshness when the response is sent by the cache. This includes freshness
assigned by the cache; e.g., through heuristics, local configuration, assigned by the cache; e.g., through heuristics, local configuration,
or other factors. May be negative, to indicate staleness. or other factors. May be negative, to indicate staleness.
2.5. The stored parameter 2.5. The stored parameter
skipping to change at page 7, line 41 skipping to change at page 7, line 41
o Description: [a description of the parameter semantics and value] o Description: [a description of the parameter semantics and value]
o Reference: [to a specification defining this parameter] o Reference: [to a specification defining this parameter]
See the registry at https://iana.org/assignments/http-cache-status See the registry at https://iana.org/assignments/http-cache-status
[4] for details on where to send registration requests. [4] for details on where to send registration requests.
5. IANA Considerations 5. IANA Considerations
Upon publication, please create the HTTP Cache-Status Parameters Upon publication, please create the HTTP Cache-Status Parameters
registry at https://iana.org/assignments/http-cache-statuses [5] and registry at https://iana.org/assignments/http-cache-status [5] and
populate it with the types defined in Section 2; see Section 4 for populate it with the types defined in Section 2; see Section 4 for
its associated procedures. its associated procedures.
6. Security Considerations 6. Security Considerations
Information about a cache's content can be used to infer the activity Attackers can use the information in Cache-Status to probe the
of those using it. Generally, access to sensitive information in a behaviour of the cache (and other components), and infer the activity
cache is limited to those who are authorised to access that of those using the cache. The Cache-Status header field may not
information (using a variety of techniques), so this does not create these risks on its own, but can assist attackers in exploiting
represent an attack vector in the general sense. them.
However, if the Cache-Status header field is exposed to parties who For example, knowing if a cache has stored a response can help an
are not authorised to obtain the response it occurs within, it could attacker execute a timing attack on sensitive data. Exposing the
expose information about that data. cache key can help an attacker understand modifications to the cache
key, which may assist cache poisoning attacks. See [ENTANGLE] for
details.
For example, if an attacker were able to obtain the Cache-Status The underlying risks can be mitigated with a variety of techniques
header field from a response containing sensitive information and (e.g., use of encryption and authentication; avoiding the inclusion
access were limited to one person (or limited set of people), they of attacker-controlled data in the cache key), depending on their
could determine whether that information had been accessed before. exact nature.
This is similar to the information exposed by various timing attacks,
but is arguably more reliable, since the cache is directly reporting
its state.
Mitigations include use of encryption (e.g., TLS [RFC8446])) to To avoid assisting such attacks, the Cache-Status header field can be
protect the response, and careful controls over access to response omitted, only sent when the client is authorized to receive it, or
header fields (as are present in the Web platform). When in doubt, only send sensitive information (e.g., the key parameter) when the
the Cache-Status header field can be omitted. client is authorized.
7. References 7. References
7.1. Normative References 7.1. Normative References
[I-D.ietf-httpbis-header-structure] [I-D.ietf-httpbis-header-structure]
Nottingham, M. and P. Kamp, "Structured Field Values for Nottingham, M. and P. Kamp, "Structured Field Values for
HTTP", draft-ietf-httpbis-header-structure-19 (work in HTTP", draft-ietf-httpbis-header-structure-19 (work in
progress), June 2020. progress), June 2020.
skipping to change at page 9, line 7 skipping to change at page 9, line 7
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[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>.
7.2. Informative References 7.2. Informative References
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [ENTANGLE]
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Kettle, J., "Web Cache Entanglement: Novel Pathways to
<https://www.rfc-editor.org/info/rfc8446>. Poisoning", n.d., <https://i.blackhat.com/USA-
20/Wednesday/us-20-Kettle-Web-Cache-Entanglement-Novel-
Pathways-To-Poisoning-wp.pdf>.
7.3. URIs 7.3. URIs
[1] https://lists.w3.org/Archives/Public/ietf-http-wg/ [1] https://lists.w3.org/Archives/Public/ietf-http-wg/
[2] https://httpwg.org/ [2] https://httpwg.org/
[3] https://github.com/httpwg/http-extensions/labels/cache-header [3] https://github.com/httpwg/http-extensions/labels/cache-header
[4] https://iana.org/assignments/http-cache-status [4] https://iana.org/assignments/http-cache-status
[5] https://iana.org/assignments/http-cache-statuses [5] https://iana.org/assignments/http-cache-status
Author's Address Author's Address
Mark Nottingham Mark Nottingham
Fastly Fastly
made in made in
Prahran, VIC Prahran, VIC
Australia Australia
Email: mnot@mnot.net Email: mnot@mnot.net
 End of changes. 13 change blocks. 
37 lines changed or deleted 37 lines changed or added

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