Re: H2 vs HPACK header table size... again

On Fri, Dec 24, 2021 at 11:50:25AM +1100, Martin Thomson wrote:
> On Fri, Dec 24, 2021, at 10:54, Kazuho Oku wrote:
> > In case of H2O / fastly.com, this is a FIXME that never has been fixed. 
> > H2O ignores SETTINGS_MAX_TABLE_SIZE.
> 
> Ahh, that's not great.  It makes <4096 pretty perilous for clients.  I wonder
> if that is the same reason for other implementations.

For haproxy we ignore it as well since we don't use it on the response
path. So this change requires us to process a setting for something we
do not use, that's a bit awkward (not *that* difficult but if forces us
to send raw HPACK bytes from the H2 code which is a direct layering
violation). And I think it's the same for other implementations as one
rarely has to implement some random tricks for things that are not used :-/

In addition I've reread RFC7541 and do not agree anymore with the change
in #1003. HPACK is clearly designed and defined as a portable compressor
and carefully avoids to mention any size, it further mentions in the text
that the limit for the table size is "determined by the protocol using
HPACK" and that "in HTTP/2 this limit is the last value of the
SETTINGS_HEADER_TABLE_SIZE parameter".

As such the magic value of 4096 has nothing to do with HPACK and is
entirely an HTTP/2 default value that is required to allow for 0.5rtt
and such to work, and that can be changed via a SETTINGS parameter.
This means that any other value advertised at the H2 layer *is* the
initial HPACK value and cannot trigger a change at the HPACK layer.

In addition, H2 was carefully designed so that HPACK could be replaced
with anything else using a new SETTINGS frame. Let's say we'd port QPACK
to H2 for example, it would seem even more gross to have to deal with
HPACK specifics in the QPACK layer for the response path.

Maybe the text could be adjusted like this:

  The dynamic table has a maximum size that is set by a decoder using the
  SETTINGS_HEADER_TABLE_SIZE setting; before receiving this setting, an
  encoder must assume an initial value of 4096 and may only use a larger
  value once it learns from this setting the size the decoder was
  initialized with.

This clearly continues to allow the client to send requests that refer
to up to 4kB of dictionary until the server announces it grows it. It
implies that a client is allowed to advertise less if desired (including
zero) since the server doesn't need to encode headers before seeing a
client's SETTINGS frame, and maintains the compatibility between existing
implementations. And more importantly it doesn't step over HPACK's feet
and makes it clear that HPACK is the only one having to speak HPACK, and
that DTSU opcodes are only related to HPACK-level changes.

Thoughts ?

Willy

Received on Friday, 24 December 2021 04:32:38 UTC