Code change:
2.2.1. <del> Given: </del> <ins> Given the following inputs: </ins> <del> "digest-value", an array of bits </del> <ins> "URL" a string corresponding to the Effective Request URI (RFC7230, Section 5.5) of a cached response RFC7234. </ins> <del> "URL", an array of characters </del> <ins> "ETag" a string corresponding to the entity-tag RFC7232 of a cached response RFC7234 (if the ETag is available; otherwise, null). </ins> <del> "ETag", an array of characters </del> <ins> "digest-value", an array of bits. Let "f" be the value of the first byte of "digest-value". Let "b" be the bucket size, defined as 4. </ins> <del> "validators", a boolean </del> <ins> Let "N" be the value of the second to fifth bytes of "digest- value" in big endian form. </ins> <del> we can determine whether there is a match in the digest using the following algorithm: </del> <ins> Let "key" be the return value of key with "URL" and "ETag" as inputs. </ins> <del> Read the first 5 bits of "digest-value" as an integer; let "N" be two raised to the power of that value. </del> <ins> Let "h1" be the return value of hash with "key" and "N" as inputs. </ins> <del> Read the next 5 bits of "digest-value" as an integer; let "P" be two raised to the power of that value. </del> <ins> Let "fingerprint" be the return value of fingerprint with "key" and "f" as inputs. </ins> <del> Let "hash-value" be the result of computing a hash value (hash). </del> <ins> Let "fingerprint-string" be the value of "fingerprint" in base 10, expressed as a string. </ins> <del> Let "C" be -1. </del> <ins> Let "h2" be the return value of hash with "fingerprint" and "N" as inputs, XORed with "h1". </ins> <del> Read '0' bits from "digest-value" until a '1' bit is found; let "Q" be the number of '0' bits.  Discard the '1'. </del> <ins> Let "h" be "h1". </ins> <del> Read log2("P") bits from "digest-value" after the '1' as an integer; let "R" be its value. </del> <ins> Let "position_start" be 40 + "h" * "f" * "b". </ins> <del> Let "D" be "Q" * "P" + "R". </del> <ins> Let "position_end" be "position_start" + "f" * "b". </ins> <del> Increment "C" by "D" + 1. </del> <ins> While "position_start" < "position_end": </ins> <del> If "C" is equal to "hash-value", return 'true'. </del> <ins> Let "bits" be "f" bits from "digest_value" starting at "position_start". </ins> <del> Otherwise, return to step 5 and continue processing; if no match is found before "digest-value" is exhausted, return 'false'. </del> <ins> If "bits" is "fingerprint", return true Add "f" to "position_start". Return false. </ins> 3. <ins> A Client SHOULD notify its support for CACHE_DIGEST frames by sending the SENDING_CACHE_DIGEST (0xXXX) SETTINGS parameter. The value of the parameter is a bit-field of which the following bits are defined: DIGEST_PENDING (0x1): When set it indicates that the client has a digest to send, and the server may choose to wait for a digest in order to make server push decisions. 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 client has no digest to send the server. 4. </ins> A server can notify its support for CACHE_DIGEST frame by sending the ACCEPT_CACHE_DIGEST (0x7) SETTINGS parameter.  If the server is tempted to making optimizations based on CACHE_DIGEST frames, it

Related discussion:
text: The reason is that I think the distinction doesn't make much sense, and maintaining it adds a lot of complexity, basically forcing browsers to recreate the digest for every connection at O(N) cost. Under this premise what servers should do is: Push all the resources that are known not to be in the cache digest Push 304 responses for resources that are in the cache digest, but are likely to be stale (short freshness lifetime, etc) Don't push resources that are in the cache digest and have a long term freshness lifetime or are immutable. Does that make sense? I'm not sure I understand your reference to the push cache vs. the HTTP cache in your comment. In light of my explanation, is there still an issue there in your view?
URL is the reference implementation. Happy to change it. Do you have any specific changes in mind?
NAME Thank you for the explanation. I now understand the intent better. I think that we need to consider two issues regarding the approach. First is the fact that a browser cache may contain more stale responses than fresh resources. Below are the numbers of cached objects found in my Firefox's cache (to be honest the date is from 2016, I haven't been using Firefox in recent weeks and therefore cannot provide up-to-date data). total ---: 2,273 1,003 As you can see, large scale websites tend to have more stale objects than fresh objects. In other words, including information of stale-cached objects increases the size of the digest roughly three times in this case. Since performance-sensitive resources (that we need to push) are likely to be stored fresh (since they are the most likely ones marked as immutable, or near-immutable), transmitting only the digest of freshly-cached responses makes sense. Second is a configuration issue on the server side. One strategy that can be employed by an H2 server (under the current draft) is to receive a digest of freshly cached resources only, compare the digest against the list of resources the browser should preload by only using the URL, and push the missing resources to the client. It is possible for a H2 server to perform the comparison without actually fetching the resource (from origin or from cache) since only the URL would be required for calculating the digest.