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: Stefan Eissing <stefan.eissing@greenbytes.de>
Date: Tue, 12 Jan 2016 10:46:23 +0100
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <BF19D095-8A69-47D0-8B9A-CEEFA8E80627@greenbytes.de>
To: Kazuho Oku <kazuhooku@gmail.com>
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 <kazuhooku@gmail.com>:
> [...]
> 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
Received on Tuesday, 12 January 2016 09:46:47 UTC

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