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

[Stefan Eissing <[e-mail]>]

Kazuho,

thanks for the draft and your work in this. I am currently implementing
a "push diary" for connections in mod_http2. This updates itself while
handling the connection, but ideally is initialized by a CACHE_DIGEST
frame.

> Am 12.01.2016 um 02:04 schrieb Kazuho Oku <[e-mail]>:
> [...]
> There are three options here (the draft adopts option C):
> 
> a) send CACHE_DIGEST frame right before HEADERS
> b) send CACHE_DIGEST frame at stream_id=zero, with the value of the
> authority that should be associated to the digest included within the
> frame
> c) send CACHE_DIGEST frame right after HEADERS
> 
> B is clearly the easiest but would have a small impact on the consumed
> bandwidth, since the authority needs to be sent separately.
> 
> In A, the server does not need to delay the processing of the request,
> but needs to cache the value of the digest.
> 
> It would be great to discuss which of the three approach will be the
> best solution in general (or if there could be other approaches).

There seems to be an underlying assumption here that CACHE_DIGEST is 
connected to a specific authority which was not immediately obvious 
to me when reading the draft.

With that in mind, I would prefer the CACHE_DIGEST frame to
carry the authority scope. That makes it self descriptive and
it can be sent on stream 0, which solves the before/after problem.

Also, I think the authority in that frame should be allowed to carry
the value '*' to allow endpoint implementations that keep one set
for all authorities on a connection.

Additionally:

1. Just for clarification: the digest values are calculated on 
the absolute URL, :scheme+'://'+:authority+:path? Because h2o
currently uses only :path, if I read it right.

2. Would it make sense to limit N and P, so that (N*P) which is
used for modulo calculation stays in unsigned 32 bit? Even with
N==P it would work up to 65K, if I am not mistaken...

-Stefan

> -- 
> Kazuho Oku