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: Resolves URL
cc NAME NAME
Hey Yoav, Thanks; will take a look. Two immediate things: You're getting a error in the markdown; . I see you've added yourself as an author. That's generally the decision of the chair - NAME in this case.
Hopefully fixed. Is there a way to test it locally? Apologies for the noobness. Removed myself.
See URL for build info.
NAME Thank you for working on the proposal. Am I correct in assuming that changes other than the switch to Cuckoo filters and the introduction are unintentional? For example, I see flag of the frame being removed. Do you have a working code that implements Cuckoo filters? I am curious to see it working. The concept of makes sense to me. Maybe we might want to adjust the codepoints and the naming in relation to .
Oh, I now understand the intent of removing the flag. The motive of the proposal is to build a digest without referring to every response object stored in cache. The fact means that it is not be easy for the client to determine the freshness of the entries that is going to be included in the digest. I am sympathetic to the idea, but I am afraid if the approach works well with the current mechanism of HTTP/2 caching. My understanding is that browsers that exist today only consume a pushed response when it fails to find a freshly cached response in its cache. Otherwise, the pushed response never lands in the browser cache. Unless we change the behavior of the browsers to respect the pushed response even if a freshly cached object already exists in its cache, there's a chance that servers would continually push responses that gets ignored by the client (due to the existence of a freshly cached response in the browser cache with the same URL). NAME Assuming that I correctly understand the motive of removing the distinction between a fresh digest and a stale digest, I would appreciate it if you could clarify your ideas on the problem.
Thanks for reviewing, NAME :) My intent was to include all stored resources in the digest, regardless of them being stale or fresh. Entries are added to the digest when a resource is added to the cache and removed from the digest when a resource is removed.