idnits 2.17.1 draft-ietf-httpbis-cache-digest-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 6, 2018) is 2205 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7232 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7234 (Obsoleted by RFC 9111) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTP Working Group K. Oku 3 Internet-Draft Fastly 4 Intended status: Experimental Y. Weiss 5 Expires: October 8, 2018 Akamai 6 April 6, 2018 8 Cache Digests for HTTP/2 9 draft-ietf-httpbis-cache-digest-04 11 Abstract 13 This specification defines a HTTP/2 frame type to allow clients to 14 inform the server of their cache's contents. Servers can then use 15 this to inform their choices of what to push to clients. 17 Note to Readers 19 Discussion of this draft takes place on the HTTP working group 20 mailing list (ietf-http-wg@w3.org), which is archived at 21 https://lists.w3.org/Archives/Public/ietf-http-wg/ . 23 Working Group information can be found at http://httpwg.github.io/ ; 24 source code and issues list for this draft can be found at 25 https://github.com/httpwg/http-extensions/labels/cache-digest . 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on October 8, 2018. 44 Copyright Notice 46 Copyright (c) 2018 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 63 2. The CACHE_DIGEST Frame . . . . . . . . . . . . . . . . . . . 3 64 2.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 4 65 2.1.1. Creating a digest . . . . . . . . . . . . . . . . . . 5 66 2.1.2. Adding a URL to the Digest-Value . . . . . . . . . . 6 67 2.1.3. Removing a URL to the Digest-Value . . . . . . . . . 7 68 2.1.4. Computing a fingerprint value . . . . . . . . . . . . 8 69 2.1.5. Computing the key . . . . . . . . . . . . . . . . . . 9 70 2.1.6. Computing a Hash Value . . . . . . . . . . . . . . . 10 71 2.1.7. Computing an Alternative Hash Value . . . . . . . . . 10 72 2.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 10 73 2.2.1. Querying the Digest for a Value . . . . . . . . . . . 11 74 3. The SENDING_CACHE_DIGEST SETTINGS Parameter . . . . . . . . . 12 75 4. The ACCEPT_CACHE_DIGEST SETTINGS Parameter . . . . . . . . . 12 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 78 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 7.1. Normative References . . . . . . . . . . . . . . . . . . 14 80 7.2. Informative References . . . . . . . . . . . . . . . . . 15 81 Appendix A. Encoding the CACHE_DIGEST frame as an HTTP Header . 16 82 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 17 83 Appendix C. Changes . . . . . . . . . . . . . . . . . . . . . . 17 84 C.1. Since draft-ietf-httpbis-cache-digest-03 . . . . . . . . 17 85 C.2. Since draft-ietf-httpbis-cache-digest-02 . . . . . . . . 17 86 C.3. Since draft-ietf-httpbis-cache-digest-01 . . . . . . . . 17 87 C.4. Since draft-ietf-httpbis-cache-digest-00 . . . . . . . . 18 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 90 1. Introduction 92 HTTP/2 [RFC7540] allows a server to "push" synthetic request/response 93 pairs into a client's cache optimistically. While there is strong 94 interest in using this facility to improve perceived Web browsing 95 performance, it is sometimes counterproductive because the client 96 might already have cached the "pushed" response. 98 When this is the case, the bandwidth used to "push" the response is 99 effectively wasted, and represents opportunity cost, because it could 100 be used by other, more relevant responses. HTTP/2 allows a stream to 101 be cancelled by a client using a RST_STREAM frame in this situation, 102 but there is still at least one round trip of potentially wasted 103 capacity even then. 105 This specification defines a HTTP/2 frame type to allow clients to 106 inform the server of their cache's contents using a Cuckoo-filter 107 [Cuckoo] based digest. Servers can then use this to inform their 108 choices of what to push to clients. 110 1.1. Notational Conventions 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. 116 2. The CACHE_DIGEST Frame 118 The CACHE_DIGEST frame type is 0xd (decimal 13). 120 +-------------------------------+-------------------------------+ 121 | Origin-Len (16) | Origin? (\*) ... 122 +-------------------------------+-------------------------------+ 123 | Digest-Value? (\*) ... 124 +---------------------------------------------------------------+ 126 The CACHE_DIGEST frame payload has the following fields: 128 Origin-Len: An unsigned, 16-bit integer indicating the length, in 129 octets, of the Origin field. 131 Origin: A sequence of characters containing the ASCII serialization 132 of an origin ([RFC6454], Section 6.2) that the Digest-Value 133 applies to. 135 Digest-Value: A sequence of octets containing the digest as computed 136 in Section 2.1.1 and Section 2.1.2. 138 The CACHE_DIGEST frame defines the following flags: 140 o *RESET* (0x1): When set, indicates that any and all cache digests 141 for the applicable origin held by the recipient MUST be considered 142 invalid. 144 o *COMPLETE* (0x2): When set, indicates that the currently valid set 145 of cache digests held by the server constitutes a complete 146 representation of the cache's state regarding that origin, for the 147 type of cached response indicated by the "STALE" flag. 149 o *VALIDATORS* (0x4): When set, indicates that the "validators" 150 boolean in Section 2.1.5 is true. 152 o *STALE* (0x8): When set, indicates that all cached responses 153 represented in the digest-value are stale [RFC7234] at the point 154 in them that the digest was generated; otherwise, all are fresh. 156 2.1. Client Behavior 158 A CACHE_DIGEST frame MUST be sent from a client to a server on stream 159 0, and conveys a digest of the contents of the client's cache for the 160 indicated origin. 162 In typical use, a client will send one or more CACHE_DIGESTs 163 immediately after the first request on a connection for a given 164 origin, on the same stream, because there is usually a short period 165 of inactivity then, and servers can benefit most when they understand 166 the state of the cache before they begin pushing associated assets 167 (e.g., CSS, JavaScript and images). Clients MAY send CACHE_DIGEST at 168 other times. 170 If the cache's state is cleared, lost, or the client otherwise wishes 171 the server to stop using previously sent CACHE_DIGESTs, it can send a 172 CACHE_DIGEST with the RESET flag set. 174 When generating CACHE_DIGEST, a client MUST NOT include cached 175 responses whose URLs do not share origins [RFC6454] with the 176 indicated origin. Clients MUST NOT send CACHE_DIGEST frames on 177 connections that are not authoritative (as defined in [RFC7540], 178 10.1) for the indicated origin. 180 CACHE_DIGEST allows the client to indicate whether the set of URLs 181 used to compute the digest represent fresh or stale stored responses, 182 using the STALE flag. Clients MAY decide whether to only send 183 CACHE_DIGEST frames representing their fresh stored responses, their 184 stale stored responses, or both. 186 Clients can choose to only send a subset of the suitable stored 187 responses of each type (fresh or stale). However, when the 188 CACHE_DIGEST frames sent represent the complete set of stored 189 responses of a given type, the last such frame SHOULD have a COMPLETE 190 flag set, to indicate to the server that it has all relevant state of 191 that type. Note that for the purposes of COMPLETE, responses cached 192 since the beginning of the connection or the last RESET flag on a 193 CACHE_DIGEST frame need not be included. 195 CACHE_DIGEST can be computed to include cached responses' ETags, as 196 indicated by the VALIDATORS flag. This information can be used by 197 servers to decide what kinds of responses to push to clients; for 198 example, a stale response that hasn't changed could be refreshed with 199 a 304 (Not Modified) response; one that has changed can be replaced 200 with a 200 (OK) response, whether the cached response was fresh or 201 stale. 203 CACHE_DIGEST has no defined meaning when sent from servers, and 204 SHOULD be ignored by clients. 206 2.1.1. Creating a digest 208 Given the following inputs: 210 o "P", an integer smaller than 256, that indicates the probability 211 of a false positive that is acceptable, expressed as "1/2\*\*P". 213 o "N", an integer that represents the number of entries - a prime 214 number smaller than 2**32 216 1. Let "f" be the number of bits per fingerprint, calculated as "P + 217 3" 219 2. Let "b" be the bucket size, defined as 4. 221 3. Let "allocated" be the closest power of 2 that is larger than 222 "N". 224 4. Let "bytes" be "f"*"allocated"*"b"/8 rounded up to the nearest 225 integer 227 5. Add 5 to "bytes" 229 6. Allocate memory of "bytes" and set it to zero. Assign it to 230 "digest-value". 232 7. Set the first byte to "P" 234 8. Set the second till fifth bytes to "N" in big endian form 236 9. Return the "digest-value". 238 Note: "allocated" is necessary due to the nature of the way Cuckoo 239 filters are creating the secondary hash, by XORing the initial hash 240 and the fingerprint's hash. The XOR operation means that secondary 241 hash can pick an entry beyond the initial number of entries, up to 242 the next power of 2. In order to avoid issues there, we allocate the 243 table appropriately. For increased space efficiency, it is 244 recommended that implementations pick a number of entries that's 245 close to the next power of 2. 247 2.1.2. Adding a URL to the Digest-Value 249 Given the following inputs: 251 o "URL" a string corresponding to the Effective Request URI 252 ([RFC7230], Section 5.5) of a cached response [RFC7234] 254 o "ETag" a string corresponding to the entity-tag [RFC7232] of a 255 cached response [RFC7234] (if the ETag is available; otherwise, 256 null); 258 o "maxcount" - max number of cuckoo hops 260 o "digest-value" 262 1. Let "f" be the value of the first byte of "digest-value". 264 2. Let "b" be the bucket size, defined as 4. 266 3. Let "N" be the value of the second to fifth bytes of "digest- 267 value" in big endian form. 269 4. Let "key" be the return value of Section 2.1.5 with "URL" and 270 "ETag" as inputs. 272 5. Let "h1" be the return value of Section 2.1.6 with "key" and "N" 273 as inputs. 275 6. Let "dest_fingerprint" be the return value of Section 2.1.4 with 276 "key" and "f" as inputs. 278 7. Let "h2" be the return value of Section 2.1.7 with "h1", 279 "dest_fingerprint" and "N" as inputs. 281 8. Let "h" be either "h1" or "h2", picked in random. 283 9. While "maxcount" is larger than zero: 285 1. Let "position_start" be 40 + "h" * "f" * "b". 287 2. Let "position_end" be "position_start" + "f" * "b". 289 3. While "position_start" < "position_end": 291 1. Let "bits" be "f" bits from "digest_value" starting at 292 "position_start". 294 2. If "bits" is all zeros, set "bits" to 295 "dest_fingerprint" and terminate these steps. 297 3. Add "f" to "position_start". 299 4. Let "e" be a random number from 0 to "b". 301 5. Subtract "f" * ("b" - "e") from "position_start". 303 6. Let "bits" be "f" bits from "digest_value" starting at 304 "position_start". 306 7. Let "fingerprint" be the value of bits, read as big endian. 308 8. Set "bits" to "dest_fingerprint". 310 9. Set "dest_fingerprint" to "fingerprint". 312 10. Let "h" be Section 2.1.7 with "h", "dest_fingerprint" and 313 "N" as inputs. 315 11. Subtract 1 from "maxcount". 317 10. Subtract "f" from "position_start". 319 11. Let "fingerprint" be the "f" bits starting at "position_start". 321 12. Let "h1" be "h" 323 13. Subtract 1 from "maxcount". 325 14. If "maxcount" is zero, return an error. 327 15. Go to step 7. 329 2.1.3. Removing a URL to the Digest-Value 331 Given the following inputs: 333 o "URL" a string corresponding to the Effective Request URI 334 ([RFC7230], Section 5.5) of a cached response [RFC7234] 336 o "ETag" a string corresponding to the entity-tag [RFC7232] of a 337 cached response [RFC7234] (if the ETag is available; otherwise, 338 null); 340 o "digest-value" 342 1. Let "f" be the value of the first byte of "digest-value". 344 2. Let "b" be the bucket size, defined as 4. 346 3. Let "N" be the value of the second to fifth bytes of "digest- 347 value" in big endian form. 349 4. Let "key" be the return value of Section 2.1.5 with "URL" and 350 "ETag" as inputs. 352 5. Let "h1" be the return value of Section 2.1.6 with "key" and "N" 353 as inputs. 355 6. Let "fingerprint" be the return value of Section 2.1.4 with "key" 356 and "f" as inputs. 358 7. Let "h2" be the return value of Section 2.1.7 with "h1", 359 "fingerprint" and "N" as inputs. 361 8. Let "hashes" be an array containing "h1" and "h2". 363 9. For each "h" in "hashes": 365 1. Let "position_start" be 40 + "h" * "f" * "b". 367 2. Let "position_end" be "position_start" + "f" * "b". 369 3. While "position_start" < "position_end": 371 1. Let "bits" be "f" bits from "digest_value" starting at 372 "position_start". 374 2. If "bits" is "fingerprint", set "bits" to all zeros and 375 terminate these steps. 377 3. Add "f" to "position_start". 379 2.1.4. Computing a fingerprint value 381 Given the following inputs: 383 o "key", an array of characters 385 o "f", an integer indicating the number of output bits 386 1. Let "hash-value" be the SHA-256 message digest [RFC6234] of 387 "key", expressed as an integer. 389 2. Let "h" be the number of bits in "hash-value" 391 3. Let "fingerprint-value" be 0 393 4. While "fingerprint-value" is 0 and "h" > "f": 395 1. Let "fingerprint-value" be the "f" least significant bits of 396 "hash-value". 398 2. Let "hash-value" be the "h"-"f" most significant bits of 399 "hash-value". 401 3. Subtract "f" from "h". 403 5. If "fingerprint-value" is 0, let "fingerprint-value" be 1. 405 6. Return "fingerprint-value". 407 Note: Step 5 is to handle the extremely unlikely case where a SHA-256 408 digest of "key" is all zeros. The implications of it means that 409 there's an infitisimaly larger probability of getting a "fingerprint- 410 value" of 1 compared to all other values. This is not a problem for 411 any practical purpose. 413 2.1.5. Computing the key 415 Given the following inputs: 417 o "URL", an array of characters 419 o "ETag", an array of characters 421 o "validators", a boolean indicating whether validators ([RFC7232]) 422 are to be included in the digest 424 1. Let "key" be "URL" converted to an ASCII string by percent- 425 encoding as appropriate [RFC3986]. 427 2. If "validators" is true and "ETag" is not null: 429 1. Append "ETag" to "key" as an ASCII string, including both the 430 "weak" indicator (if present) and double quotes, as per 431 [RFC7232], Section 2.3. 433 3. Return "key" 434 TODO: Add an example of the ETag and the key calcuations. 436 2.1.6. Computing a Hash Value 438 Given the following inputs: 440 o "key", an array of characters. 442 o "N", an integer 444 "hash-value" can be computed using the following algorithm: 446 1. Let "hash-value" be the SHA-256 message digest [RFC6234] of 447 "key", truncated to 32 bits, expressed as an integer. 449 2. Return "hash-value" modulo N. 451 2.1.7. Computing an Alternative Hash Value 453 Given the following inputs: 455 o "hash1", an integer indicating the previous hash. 457 o "fingerprint", an integer indicating the fingerprint value. 459 o "N", an integer indicating the number of entries in the digest. 461 1. Let "fingerprint-string" be the value of "fingerprint" in base 462 10, expressed as a string. 464 2. Let "hash2" be the return value of Section 2.1.6 with 465 "fingerprint-string" and "N" as inputs, XORed with "hash1". 467 3. Return "hash2". 469 2.2. Server Behavior 471 In typical use, a server will query (as per Section 2.2.1) the 472 CACHE_DIGESTs received on a given connection to inform what it pushes 473 to that client; 475 o If a given URL and ETag combination has a match in a current 476 CACHE_DIGEST, a complete response need not be pushed; The server 477 MAY push a 304 response for that resource, indicating the client 478 that it hasn't changed. 480 o If a given URL and ETag has no match in any current CACHE_DIGEST, 481 the client does not have a cached copy, and a complete response 482 can be pushed. 484 Servers MAY use all CACHE_DIGESTs received for a given origin as 485 current, as long as they do not have the RESET flag set; a 486 CACHE_DIGEST frame with the RESET flag set MUST clear any previously 487 stored CACHE_DIGESTs for its origin. Servers MUST treat an empty 488 Digest-Value with a RESET flag set as effectively clearing all stored 489 digests for that origin. 491 Clients are not likely to send updates to CACHE_DIGEST over the 492 lifetime of a connection; it is expected that servers will separately 493 track what cacheable responses have been sent previously on the same 494 connection, using that knowledge in conjunction with that provided by 495 CACHE_DIGEST. 497 Servers MUST ignore CACHE_DIGEST frames sent on a stream other than 498 0. 500 2.2.1. Querying the Digest for a Value 502 Given the following inputs: 504 o "URL" a string corresponding to the Effective Request URI 505 ([RFC7230], Section 5.5) of a cached response [RFC7234]. 507 o "ETag" a string corresponding to the entity-tag [RFC7232] of a 508 cached response [RFC7234] (if the ETag is available; otherwise, 509 null). 511 o "validators", a boolean 513 o "digest-value", an array of bits. 515 1. Let "f" be the value of the first byte of "digest-value". 517 2. Let "b" be the bucket size, defined as 4. 519 3. Let "N" be the value of the second to fifth bytes of "digest- 520 value" in big endian form. 522 4. Let "key" be the return value of Section 2.1.5 with "URL" and 523 "ETag" as inputs. 525 5. Let "h1" be the return value of Section 2.1.6 with "key" and "N" 526 as inputs. 528 6. Let "fingerprint" be the return value of Section 2.1.4 with 529 "key" and "f" as inputs. 531 7. Let "h2" be the return value of Section 2.1.7 with "h1", 532 "fingerprint" and "N" as inputs. 534 8. Let "hashes" be an array containing "h1" and "h2". 536 9. For each "h" in "hashes": 538 1. Let "position_start" be 40 + "h" * "f" * "b". 540 2. Let "position_end" be "position_start" + "f" * "b". 542 3. While "position_start" < "position_end": 544 1. Let "bits" be "f" bits from "digest_value" starting at 545 "position_start". 547 2. If "bits" is "fingerprint", return true 549 3. Add "f" to "position_start". 551 10. Return false. 553 3. The SENDING_CACHE_DIGEST SETTINGS Parameter 555 A Client SHOULD notify its support for CACHE_DIGEST frames by sending 556 the SENDING_CACHE_DIGEST (0xXXX) SETTINGS parameter. 558 The value of the parameter is a bit-field of which the following bits 559 are defined: 561 DIGEST_PENDING (0x1): When set it indicates that the client has a 562 digest to send, and the server may choose to wait for a digest in 563 order to make server push decisions. 565 Rest of the bits MUST be ignored and MUST be left unset when sending. 567 The initial value of the parameter is zero (0x0) meaning that the 568 client has no digest to send the server. 570 4. The ACCEPT_CACHE_DIGEST SETTINGS Parameter 572 A server can notify its support for CACHE_DIGEST frame by sending the 573 ACCEPT_CACHE_DIGEST (0x7) SETTINGS parameter. If the server is 574 tempted to making optimizations based on CACHE_DIGEST frames, it 575 SHOULD send the SETTINGS parameter immediately after the connection 576 is established. 578 The value of the parameter is a bit-field of which the following bits 579 are defined: 581 ACCEPT (0x1): When set, it indicates that the server is willing to 582 make use of a digest of cached responses. 584 Rest of the bits MUST be ignored and MUST be left unset when sending. 586 The initial value of the parameter is zero (0x0) meaning that the 587 server is not interested in seeing a CACHE_DIGEST frame. 589 Some underlying transports allow the server's first flight of 590 application data to reach the client at around the same time when the 591 client sends it's first flight data. When such transport (e.g., TLS 592 1.3 [I-D.ietf-tls-tls13] in full-handshake mode) is used, a client 593 can postpone sending the CACHE_DIGEST frame until it receives a 594 ACCEPT_CACHE_DIGEST settings value. 596 When the underlying transport does not have such property (e.g., TLS 597 1.3 in 0-RTT mode), a client can reuse the settings value found in 598 previous connections to that origin [RFC6454] to make assumptions. 600 5. IANA Considerations 602 This document registers the following entry in the Permanent Message 603 Headers Registry, as per [RFC3864]: 605 o Header field name: Cache-Digest 607 o Applicable protocol: http 609 o Status: experimental 611 o Author/Change controller: IESG 613 o Specification document(s): [this document] 615 This document registers the following entry in the HTTP/2 Frame Type 616 Registry, as per [RFC7540]: 618 o Frame Type: CACHE_DIGEST 620 o Code: 0xd 622 o Specification: [this document] 623 This document registers the following entry in the HTTP/2 Settings 624 Registry, as per [RFC7540]: 626 o Code: 0x7 628 o Name: ACCEPT_CACHE_DIGEST 630 o Initial Value: 0x0 632 o Reference: [this document] 634 6. Security Considerations 636 The contents of a User Agent's cache can be used to re-identify or 637 "fingerprint" the user over time, even when other identifiers (e.g., 638 Cookies [RFC6265]) are cleared. 640 CACHE_DIGEST allows such cache-based fingerprinting to become 641 passive, since it allows the server to discover the state of the 642 client's cache without any visible change in server behaviour. 644 As a result, clients MUST mitigate for this threat when the user 645 attempts to remove identifiers (e.g., "clearing cookies"). This 646 could be achieved in a number of ways; for example: by clearing the 647 cache, by changing one or both of N and P, or by adding new, 648 synthetic entries to the digest to change its contents. 650 TODO: discuss how effective the suggested mitigations actually would 651 be. 653 Additionally, User Agents SHOULD NOT send CACHE_DIGEST when in 654 "privacy mode." 656 7. References 658 7.1. Normative References 660 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 661 Requirement Levels", BCP 14, RFC 2119, 662 DOI 10.17487/RFC2119, March 1997, . 665 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 666 Resource Identifier (URI): Generic Syntax", STD 66, 667 RFC 3986, DOI 10.17487/RFC3986, January 2005, 668 . 670 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 671 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 672 DOI 10.17487/RFC6234, May 2011, . 675 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 676 DOI 10.17487/RFC6454, December 2011, . 679 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 680 Protocol (HTTP/1.1): Message Syntax and Routing", 681 RFC 7230, DOI 10.17487/RFC7230, June 2014, 682 . 684 [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 685 Protocol (HTTP/1.1): Conditional Requests", RFC 7232, 686 DOI 10.17487/RFC7232, June 2014, . 689 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 690 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 691 RFC 7234, DOI 10.17487/RFC7234, June 2014, 692 . 694 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 695 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 696 DOI 10.17487/RFC7540, May 2015, . 699 7.2. Informative References 701 [Cuckoo] "Cuckoo Filter: Practically Better Than Bloom", n.d., 702 . 705 [Fetch] "Fetch Standard", n.d., . 707 [I-D.ietf-tls-tls13] 708 Rescorla, E., "The Transport Layer Security (TLS) Protocol 709 Version 1.3", draft-ietf-tls-tls13-28 (work in progress), 710 March 2018. 712 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 713 Procedures for Message Header Fields", BCP 90, RFC 3864, 714 DOI 10.17487/RFC3864, September 2004, . 717 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 718 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 719 . 721 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 722 Specifications: ABNF", STD 68, RFC 5234, 723 DOI 10.17487/RFC5234, January 2008, . 726 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 727 DOI 10.17487/RFC6265, April 2011, . 730 [Service-Workers] 731 Russell, A., Song, J., Archibald, J., and M. 732 Kruisselbrink, "Service Workers 1", W3C Working Draft WD- 733 service-workers-1-20161011, October 2016, 734 . 737 Appendix A. Encoding the CACHE_DIGEST frame as an HTTP Header 739 On some web browsers that support Service Workers [Service-Workers] 740 but not Cache Digests (yet), it is possible to achieve the benefit of 741 using Cache Digests by emulating the frame using HTTP Headers. 743 For the sake of interoperability with such clients, this appendix 744 defines how a CACHE_DIGEST frame can be encoded as an HTTP header 745 named "Cache-Digest". 747 The definition uses the Augmented Backus-Naur Form (ABNF) notation of 748 [RFC5234] with the list rule extension defined in [RFC7230], 749 Section 7. 751 Cache-Digest = 1#digest-entity 752 digest-entity = digest-value *(OWS ";" OWS digest-flag) 753 digest-value = 754 digest-flag = token 756 A Cache-Digest request header is defined as a list construct of 757 cache-digest-entities. Each cache-digest-entity corresponds to a 758 CACHE_DIGEST frame. 760 Digest-Value is encoded using base64url [RFC4648], Section 5. Flags 761 that are set are encoded as digest-flags by their names that are 762 compared case-insensitively. 764 Origin is omitted in the header form. The value is implied from the 765 value of the ":authority" pseudo header. Client MUST only send 766 Cache-Digest headers containing digests that belong to the origin 767 specified by the HTTP request. 769 The example below contains one digest of fresh resource and has only 770 the "COMPLETE" flag set. 772 Cache-Digest: AfdA; complete 774 Clients MUST associate Cache-Digest headers to every HTTP request, 775 since Fetch [Fetch] - the HTTP API supported by Service Workers - 776 does not define the order in which the issued requests will be sent 777 to the server nor guarantees that all the requests will be 778 transmitted using a single HTTP/2 connection. 780 Also, due to the fact that any header that is supplied to Fetch is 781 required to be end-to-end, there is an ambiguity in what a Cache- 782 Digest header respresents when a request is transmitted through a 783 proxy. The header may represent the cache state of a client or that 784 of a proxy, depending on how the proxy handles the header. 786 Appendix B. Acknowledgements 788 Thanks to Stefan Eissing for his suggestions. 790 Appendix C. Changes 792 C.1. Since draft-ietf-httpbis-cache-digest-03 794 o Yoav becomes an author; Mark steps down. 796 C.2. Since draft-ietf-httpbis-cache-digest-02 798 o Switch to Cuckoo Filter. 800 C.3. Since draft-ietf-httpbis-cache-digest-01 802 o Added definition of the Cache-Digest header. 804 o Introduce ACCEPT_CACHE_DIGEST SETTINGS parameter. 806 o Change intended status from Standard to Experimental. 808 C.4. Since draft-ietf-httpbis-cache-digest-00 810 o Make the scope of a digest frame explicit and shift to stream 0. 812 Authors' Addresses 814 Kazuho Oku 815 Fastly 817 Email: kazuhooku@gmail.com 819 Yoav Weiss 820 Akamai 822 Email: yoav@yoav.ws 823 URI: https://blog.yoav.ws/