draft-ietf-httpbis-cache-digest-02.txt   draft-ietf-httpbis-cache-digest-latest.txt 
HTTP Working Group K. Oku HTTP Working Group K. Oku
Internet-Draft DeNA Co, Ltd. Internet-Draft DeNA Co, Ltd.
Intended status: Experimental M. Nottingham Intended status: Experimental M. Nottingham
Expires: December 1, 2017 May 30, 2017 Expires: December 23, 2017 June 21, 2017
Cache Digests for HTTP/2 Cache Digests for HTTP/2
draft-ietf-httpbis-cache-digest-02 draft-ietf-httpbis-cache-digest-latest
Abstract Abstract
This specification defines a HTTP/2 frame type to allow clients to This specification defines a HTTP/2 frame type to allow clients to
inform the server of their caches contents. Servers can then use inform the server of their cache's contents. Servers can then use
this to inform their choices of what to push to clients. this to inform their choices of what to push to clients.
Note to Readers Note to Readers
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 http://httpwg.github.io/; Working Group information can be found at http://httpwg.github.io/;
source code and issues list for this draft can be found at source code and issues list for this draft can be found at
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 December 1, 2017. This Internet-Draft will expire on December 23, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 34 skipping to change at page 2, line 34
2.2.1. Querying the Digest for a Value . . . . . . . . . . . 7 2.2.1. Querying the Digest for a Value . . . . . . . . . . . 7
3. The ACCEPT_CACHE_DIGEST SETTINGS Parameter . . . . . . . . . 8 3. The ACCEPT_CACHE_DIGEST SETTINGS Parameter . . . . . . . . . 8
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Normative References . . . . . . . . . . . . . . . . . . 10 6.1. Normative References . . . . . . . . . . . . . . . . . . 10
6.2. Informative References . . . . . . . . . . . . . . . . . 11 6.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Encoding the CACHE_DIGEST frame as an HTTP Header . 12 Appendix A. Encoding the CACHE_DIGEST frame as an HTTP Header . 12
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 13 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 13
Appendix C. Changes . . . . . . . . . . . . . . . . . . . . . . 13 Appendix C. Changes . . . . . . . . . . . . . . . . . . . . . . 13
C.1. Since draft-ietf-httpbis-cache-digest-01 . . . . . . . . 13 C.1. Since draft-ietf-httpbis-cache-digest-02 . . . . . . . . 13
C.2. Since draft-ietf-httpbis-cache-digest-00 . . . . . . . . 13 C.2. Since draft-ietf-httpbis-cache-digest-01 . . . . . . . . 13
C.3. Since draft-ietf-httpbis-cache-digest-00 . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
HTTP/2 [RFC7540] allows a server to “push” synthetic request/response HTTP/2 [RFC7540] allows a server to "push" synthetic request/response
pairs into a client’s cache optimistically. While there is strong pairs into a client's cache optimistically. While there is strong
interest in using this facility to improve perceived Web browsing interest in using this facility to improve perceived Web browsing
performance, it is sometimes counterproductive because the client performance, it is sometimes counterproductive because the client
might already have cached the “pushed” response. might already have cached the "pushed" response.
When this is the case, the bandwidth used to “push” the response is When this is the case, the bandwidth used to "push" the response is
effectively wasted, and represents opportunity cost, because it could effectively wasted, and represents opportunity cost, because it could
be used by other, more relevant responses. HTTP/2 allows a stream to be used by other, more relevant responses. HTTP/2 allows a stream to
be cancelled by a client using a RST_STREAM frame in this situation, be cancelled by a client using a RST_STREAM frame in this situation,
but there is still at least one round trip of potentially wasted but there is still at least one round trip of potentially wasted
capacity even then. capacity even then.
This specification defines a HTTP/2 frame type to allow clients to This specification defines a HTTP/2 frame type to allow clients to
inform the server of their caches contents using a Golomb-Rice Coded inform the server of their cache's contents using a Golomb-Rice Coded
Set [Rice]. Servers can then use this to inform their choices of Set [Rice]. Servers can then use this to inform their choices of
what to push to clients. what to push to clients.
1.1. Notational Conventions 1.1. Notational Conventions
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].
2. The CACHE_DIGEST Frame 2. The CACHE_DIGEST Frame
The CACHE_DIGEST frame type is 0xd (decimal 13). The CACHE_DIGEST frame type is 0xd (decimal 13).
+-------------------------------+-------------------------------+ +-------------------------------+-------------------------------+
| Origin-Len (16) | Origin? (\*) ... | Origin-Len (16) | Origin? (\*) ...
+-------------------------------+-------------------------------+ +-------------------------------+-------------------------------+
| Digest-Value? (\*) ... | Digest-Value? (\*) ...
skipping to change at page 3, line 46 skipping to change at page 3, line 46
in Section 2.1.1. in Section 2.1.1.
The CACHE_DIGEST frame defines the following flags: The CACHE_DIGEST frame defines the following flags:
o *RESET* (0x1): When set, indicates that any and all cache digests o *RESET* (0x1): When set, indicates that any and all cache digests
for the applicable origin held by the recipient MUST be considered for the applicable origin held by the recipient MUST be considered
invalid. invalid.
o *COMPLETE* (0x2): When set, indicates that the currently valid set o *COMPLETE* (0x2): When set, indicates that the currently valid set
of cache digests held by the server constitutes a complete of cache digests held by the server constitutes a complete
representation of the caches state regarding that origin, for the representation of the cache's state regarding that origin, for the
type of cached response indicated by the "STALE" flag. type of cached response indicated by the "STALE" flag.
o *VALIDATORS* (0x4): When set, indicates that the "validators" o *VALIDATORS* (0x4): When set, indicates that the "validators"
boolean in Section 2.1.1 is true. boolean in Section 2.1.1 is true.
o *STALE* (0x8): When set, indicates that all cached responses o *STALE* (0x8): When set, indicates that all cached responses
represented in the digest-value are stale [RFC7234] at the point represented in the digest-value are stale [RFC7234] at the point
in them that the digest was generated; otherwise, all are fresh. in them that the digest was generated; otherwise, all are fresh.
2.1. Client Behavior 2.1. Client Behavior
A CACHE_DIGEST frame MUST be sent from a client to a server on stream A CACHE_DIGEST frame MUST be sent from a client to a server on stream
0, and conveys a digest of the contents of the clients cache for the 0, and conveys a digest of the contents of the client's cache for the
indicated origin. indicated origin.
In typical use, a client will send one or more CACHE_DIGESTs In typical use, a client will send one or more CACHE_DIGESTs
immediately after the first request on a connection for a given immediately after the first request on a connection for a given
origin, on the same stream, because there is usually a short period origin, on the same stream, because there is usually a short period
of inactivity then, and servers can benefit most when they understand of inactivity then, and servers can benefit most when they understand
the state of the cache before they begin pushing associated assets the state of the cache before they begin pushing associated assets
(e.g., CSS, JavaScript and images). Clients MAY send CACHE_DIGEST at (e.g., CSS, JavaScript and images). Clients MAY send CACHE_DIGEST at
other times. other times.
If the caches state is cleared, lost, or the client otherwise wishes If the cache's state is cleared, lost, or the client otherwise wishes
the server to stop using previously sent CACHE_DIGESTs, it can send a the server to stop using previously sent CACHE_DIGESTs, it can send a
CACHE_DIGEST with the RESET flag set. CACHE_DIGEST with the RESET flag set.
When generating CACHE_DIGEST, a client MUST NOT include cached When generating CACHE_DIGEST, a client MUST NOT include cached
responses whose URLs do not share origins [RFC6454] with the responses whose URLs do not share origins [RFC6454] with the
indicated origin. Clients MUST NOT send CACHE_DIGEST frames on indicated origin. Clients MUST NOT send CACHE_DIGEST frames on
connections that are not authoritative (as defined in [RFC7540], connections that are not authoritative (as defined in [RFC7540],
10.1) for the indicated origin. 10.1) for the indicated origin.
CACHE_DIGEST allows the client to indicate whether the set of URLs CACHE_DIGEST allows the client to indicate whether the set of URLs
skipping to change at page 4, line 48 skipping to change at page 4, line 48
Clients can choose to only send a subset of the suitable stored Clients can choose to only send a subset of the suitable stored
responses of each type (fresh or stale). However, when the responses of each type (fresh or stale). However, when the
CACHE_DIGEST frames sent represent the complete set of stored CACHE_DIGEST frames sent represent the complete set of stored
responses of a given type, the last such frame SHOULD have a COMPLETE responses of a given type, the last such frame SHOULD have a COMPLETE
flag set, to indicate to the server that it has all relevant state of flag set, to indicate to the server that it has all relevant state of
that type. Note that for the purposes of COMPLETE, responses cached that type. Note that for the purposes of COMPLETE, responses cached
since the beginning of the connection or the last RESET flag on a since the beginning of the connection or the last RESET flag on a
CACHE_DIGEST frame need not be included. CACHE_DIGEST frame need not be included.
CACHE_DIGEST can be computed to include cached responses ETags, as CACHE_DIGEST can be computed to include cached responses' ETags, as
indicated by the VALIDATORS flag. This information can be used by indicated by the VALIDATORS flag. This information can be used by
servers to decide what kinds of responses to push to clients; for servers to decide what kinds of responses to push to clients; for
example, a stale response that hasnt changed could be refreshed with example, a stale response that hasn't changed could be refreshed with
a 304 (Not Modified) response; one that has changed can be replaced a 304 (Not Modified) response; one that has changed can be replaced
with a 200 (OK) response, whether the cached response was fresh or with a 200 (OK) response, whether the cached response was fresh or
stale. stale.
CACHE_DIGEST has no defined meaning when sent from servers, and CACHE_DIGEST has no defined meaning when sent from servers, and
SHOULD be ignored by clients. SHOULD be ignored by clients.
2.1.1. Computing the Digest-Value 2.1.1. Computing the Digest-Value
Given the following inputs: Given the following inputs:
skipping to change at page 5, line 29 skipping to change at page 5, line 29
Section 5.5) of a cached response [RFC7234] and its entity-tag Section 5.5) of a cached response [RFC7234] and its entity-tag
[RFC7232] (if "validators" is true and if the ETag is available; [RFC7232] (if "validators" is true and if the ETag is available;
otherwise, null); otherwise, null);
o "P", an integer that MUST be a power of 2 smaller than 2**32, that o "P", an integer that MUST be a power of 2 smaller than 2**32, that
indicates the probability of a false positive that is acceptable, indicates the probability of a false positive that is acceptable,
expressed as "1/P". expressed as "1/P".
"digest-value" can be computed using the following algorithm: "digest-value" can be computed using the following algorithm:
1. Let N be the count of "URLs" members, rounded to the nearest 1. Let N be the count of "URLs"' members, rounded to the nearest
power of 2 smaller than 2**32. power of 2 smaller than 2**32.
2. Let "hash-values" be an empty array of integers. 2. Let "hash-values" be an empty array of integers.
3. For each ("URL", "ETag") in "URLs", compute a hash value 3. For each ("URL", "ETag") in "URLs", compute a hash value
(Section 2.1.2) and append the result to "hash-values". (Section 2.1.2) and append the result to "hash-values".
4. Sort "hash-values" in ascending order. 4. Sort "hash-values" in ascending order.
5. Let "digest-value" be an empty array of bits. 5. Let "digest-value" be an empty array of bits.
skipping to change at page 6, line 9 skipping to change at page 6, line 9
9. For each "V" in "hash-values": 9. For each "V" in "hash-values":
1. If "V" is equal to "C", continue to the next "V". 1. If "V" is equal to "C", continue to the next "V".
2. Let "D" be the result of "V - C - 1". 2. Let "D" be the result of "V - C - 1".
3. Let "Q" be the integer result of "D / P". 3. Let "Q" be the integer result of "D / P".
4. Let "R" be the result of "D modulo P". 4. Let "R" be the result of "D modulo P".
5. Write "Q" ‘0’ bits to "digest-value". 5. Write "Q" '0' bits to "digest-value".
6. Write 1 ‘1’ bit to "digest-value". 6. Write 1 '1' bit to "digest-value".
7. Write "R" to "digest-value" as binary, using log2("P") bits. 7. Write "R" to "digest-value" as binary, using log2("P") bits.
8. Let "C" be "V" 8. Let "C" be "V"
10. If the length of "digest-value" is not a multiple of 8, pad it 10. If the length of "digest-value" is not a multiple of 8, pad it
with 0s until it is. with 0s until it is.
2.1.2. Computing a Hash Value 2.1.2. Computing a Hash Value
skipping to change at page 8, line 16 skipping to change at page 8, line 16
be two raised to the power of that value. be two raised to the power of that value.
2. Read the next 5 bits of "digest-value" as an integer; let "P" be 2. Read the next 5 bits of "digest-value" as an integer; let "P" be
two raised to the power of that value. two raised to the power of that value.
3. Let "hash-value" be the result of computing a hash value 3. Let "hash-value" be the result of computing a hash value
(Section 2.1.2). (Section 2.1.2).
4. Let "C" be -1. 4. Let "C" be -1.
5. Read ‘0’ bits from "digest-value" until a ‘1’ bit is found; let 5. Read '0' bits from "digest-value" until a '1' bit is found; let
"Q" be the number of ‘0’ bits. Discard the ‘1’. "Q" be the number of '0' bits. Discard the '1'.
6. Read log2("P") bits from "digest-value" after the ‘1’ as an 6. Read log2("P") bits from "digest-value" after the '1' as an
integer; let "R" be its value. integer; let "R" be its value.
7. Let "D" be "Q" * "P" + "R". 7. Let "D" be "Q" * "P" + "R".
8. Increment "C" by "D" + 1. 8. Increment "C" by "D" + 1.
9. If "C" is equal to "hash-value", return ‘true’. 9. If "C" is equal to "hash-value", return 'true'.
10. Otherwise, return to step 5 and continue processing; if no match 10. Otherwise, return to step 5 and continue processing; if no match
is found before "digest-value" is exhausted, return ‘false’. is found before "digest-value" is exhausted, return 'false'.
3. The ACCEPT_CACHE_DIGEST SETTINGS Parameter 3. The ACCEPT_CACHE_DIGEST SETTINGS Parameter
A server can notify its support for CACHE_DIGEST frame by sending the A server can notify its support for CACHE_DIGEST frame by sending the
ACCEPT_CACHE_DIGEST (0x7) SETTINGS parameter. If the server is ACCEPT_CACHE_DIGEST (0x7) SETTINGS parameter. If the server is
tempted to making optimizations based on CACHE_DIGEST frames, it tempted to making optimizations based on CACHE_DIGEST frames, it
SHOULD send the SETTINGS parameter immediately after the connection SHOULD send the SETTINGS parameter immediately after the connection
is established. is established.
The value of the parameter is a bit-field of which the following bits The value of the parameter is a bit-field of which the following bits
skipping to change at page 9, line 5 skipping to change at page 9, line 5
make use of a digest of freshly-cached responses. make use of a digest of freshly-cached responses.
STALE (0x2): When set, it indicates that the server is willing to STALE (0x2): When set, it indicates that the server is willing to
make use of a digest of stale-cached responses. make use of a digest of stale-cached responses.
Rest of the bits MUST be ignored and MUST be left unset when sending. Rest of the bits MUST be ignored and MUST be left unset when sending.
The initial value of the parameter is zero (0x0) meaning that the The initial value of the parameter is zero (0x0) meaning that the
server is not interested in seeing a CACHE_DIGEST frame. server is not interested in seeing a CACHE_DIGEST frame.
Some underlying transports allow the servers first flight of Some underlying transports allow the server's first flight of
application data to reach the client at around the same time when the application data to reach the client at around the same time when the
client sends its first flight data. When such transport (e.g., TLS client sends it's first flight data. When such transport (e.g., TLS
1.3 [I-D.ietf-tls-tls13] in full-handshake mode) is used, a client 1.3 [I-D.ietf-tls-tls13] in full-handshake mode) is used, a client
can postpone sending the CACHE_DIGEST frame until it receives a can postpone sending the CACHE_DIGEST frame until it receives a
ACCEPT_CACHE_DIGEST settings value. ACCEPT_CACHE_DIGEST settings value.
When the underlying transport does not have such property (e.g., TLS When the underlying transport does not have such property (e.g., TLS
1.3 in 0-RTT mode), a client can reuse the settings value found in 1.3 in 0-RTT mode), a client can reuse the settings value found in
previous connections to that origin [RFC6454] to make assumptions. previous connections to that origin [RFC6454] to make assumptions.
4. IANA Considerations 4. IANA Considerations
skipping to change at page 10, line 7 skipping to change at page 10, line 7
o Code: 0x7 o Code: 0x7
o Name: ACCEPT_CACHE_DIGEST o Name: ACCEPT_CACHE_DIGEST
o Initial Value: 0x0 o Initial Value: 0x0
o Reference: [this document] o Reference: [this document]
5. Security Considerations 5. Security Considerations
The contents of a User Agent’s cache can be used to re-identify or The contents of a User Agent's cache can be used to re-identify or
“fingerprint” the user over time, even when other identifiers (e.g., "fingerprint" the user over time, even when other identifiers (e.g.,
Cookies [RFC6265]) are cleared. Cookies [RFC6265]) are cleared.
CACHE_DIGEST allows such cache-based fingerprinting to become CACHE_DIGEST allows such cache-based fingerprinting to become
passive, since it allows the server to discover the state of the passive, since it allows the server to discover the state of the
clients cache without any visible change in server behaviour. client's cache without any visible change in server behaviour.
As a result, clients MUST mitigate for this threat when the user As a result, clients MUST mitigate for this threat when the user
attempts to remove identifiers (e.g., “clearing cookies”). This attempts to remove identifiers (e.g., "clearing cookies"). This
could be achieved in a number of ways; for example: by clearing the could be achieved in a number of ways; for example: by clearing the
cache, by changing one or both of N and P, or by adding new, cache, by changing one or both of N and P, or by adding new,
synthetic entries to the digest to change its contents. synthetic entries to the digest to change its contents.
TODO: discuss how effective the suggested mitigations actually would TODO: discuss how effective the suggested mitigations actually would
be. be.
Additionally, User Agents SHOULD NOT send CACHE_DIGEST when in Additionally, User Agents SHOULD NOT send CACHE_DIGEST when in
“privacy mode.” "privacy mode."
6. References 6. References
6.1. Normative References 6.1. Normative References
[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,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 13, line 25 skipping to change at page 13, line 25
Thanks to Adam Langley and Giovanni Bajo for their explorations of Thanks to Adam Langley and Giovanni Bajo for their explorations of
Golomb-coded sets. In particular, see Golomb-coded sets. In particular, see
http://giovanni.bajo.it/post/47119962313/golomb-coded-sets-smaller- http://giovanni.bajo.it/post/47119962313/golomb-coded-sets-smaller-
than-bloom-filters, which refers to sample code. than-bloom-filters, which refers to sample code.
Thanks to Stefan Eissing for his suggestions. Thanks to Stefan Eissing for his suggestions.
Appendix C. Changes Appendix C. Changes
C.1. Since draft-ietf-httpbis-cache-digest-01 C.1. Since draft-ietf-httpbis-cache-digest-02
o None yet.
C.2. Since draft-ietf-httpbis-cache-digest-01
o Added definition of the Cache-Digest header. o Added definition of the Cache-Digest header.
o Introduce ACCEPT_CACHE_DIGEST SETTINGS parameter. o Introduce ACCEPT_CACHE_DIGEST SETTINGS parameter.
o Change intended status from Standard to Experimental. o Change intended status from Standard to Experimental.
C.2. Since draft-ietf-httpbis-cache-digest-00 C.3. Since draft-ietf-httpbis-cache-digest-00
o Make the scope of a digest frame explicit and shift to stream 0. o Make the scope of a digest frame explicit and shift to stream 0.
Authors' Addresses Authors' Addresses
Kazuho Oku Kazuho Oku
DeNA Co, Ltd. DeNA Co, Ltd.
Email: kazuhooku@gmail.com Email: kazuhooku@gmail.com
Mark Nottingham Mark Nottingham
Email: mnot@mnot.net Email: mnot@mnot.net
URI: https://www.mnot.net/ URI: https://www.mnot.net/
 End of changes. 31 change blocks. 
36 lines changed or deleted 40 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/