W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2016

Re: Submitted new I-D: Cache Digests for HTTP/2

From: Kazuho Oku <kazuhooku@gmail.com>
Date: Sat, 9 Jan 2016 15:45:16 +0900
Message-ID: <CANatvzxPMBPyUy6gw8izBxev5H_ShVKM-WEyaPEnkLWB9Y6F0Q@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
2016-01-09 4:57 GMT+09:00 Martin Thomson <martin.thomson@gmail.com>:
> On 8 January 2016 at 18:17, Kazuho Oku <kazuhooku@gmail.com> wrote:
>> Please let us know how you think about the proposal.  Thank you in advance.
> This is good stuff, I'd like to see it validated, but it could be the
> thing that makes server push viable for a lot of servers.

Thank you for the positive response.

> Like Alex, I'm interested in other applications than the primary one
> you describe.  I don't think that you need to remove text about server
> push, but you should avoid making statements that restrict its use.  I
> recommend that you define the basic mechanism and then describe its
> application to your primary use case.

That approach sounds very reasonable.

Considering the fact that there are specific requirements to cache
digests for optimizing HTTP/2 push (i.e. the digest should be small /
the digest may be sent before the first HTTP/2 frame arrives from the
server), I think it would be appropriate to keep the description of
the primary use case.

> I think that the draft is lacking a description of how to consume the
> value.  That's particularly relevant as you get to the tail of the
> value.


> I wonder if we might be able to pack N and P a little more tightly by
> constraining their range just a little.  And not only because it saves
> a byte: you also want to limit the damage someone can do with the
> header field and small P would bound the size of the data.  Similarly,
> it will simplify implementations considerably if they can store
> integers in uint64_t, which is possible if log2(N) + log2(P) doesn't
> exceed 64.  I don't see any case for probabilities of 1/2^255 or 1/1;
> likewise sets of 1 resource aren't interesting, and sets of 2^255
> resources is a shade on the massive size.  2^32 is probably fine for
> both.

Thank you for the thoughtful suggestion.  Limiting the value of N and
P to be below 2^32 sounds like a very good idea.

> "key" modulo ( "N" * "P" ) should instead be constructed by truncating
> the hash to log2(N) + log2(P) bits and converting to an integer.

Agreed.  Defining the operation as truncation and conversion to an
integer will be more precise.

Thank you for the advices.

Kazuho Oku
Received on Saturday, 9 January 2016 06:45:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 22 March 2016 12:47:10 UTC