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

Thank you all for working on this.

2021年12月24日(金) 8:42 Martin Thomson <mt@lowentropy.net>:

> On Thu, Dec 23, 2021, at 19:02, Willy Tarreau wrote:
> > While running some tests on my side after adapting my code, I discovered
> > that the H2 client in the varnish-test suite doesn't seem to like very
> much
> > receiving a table size update of zero (that may be OK it's a regression
> > testing program). That led me to test varnish then a few other sites with
> > the following command:
> >
> >   $ nghttp -v -H":method: HEAD" --header-table-size=0 https://$SITE
> >
> > And the result is not as bright as initially thought:
> >   - varnish-cache.org causes a compression error
> >   - haproxy.org causes a compression error.
> >   - apache.org causes a compression error
> >   - h2o.examp1e.net causes a compression error
> >   - litespeedtech.com causes a compression error
> >   - lighttpd.net doesn't speak H2
> >   - nginx.org / .com surprisingly do not speak H2
> >   - akamai.com is OK
> >   - cloudflare.com is OK
> >   - fastly.com causes a compression error
>

In case of H2O / fastly.com, this is a FIXME that never has been fixed. H2O
ignores SETTINGS_MAX_TABLE_SIZE.

Regarding the initial size of dynamic table, I agree that it starts with
4096. When TLS 1.3 0-RTT or client authentication is used, the cilent is
first to speak. It cannot wait for the server's SETTINGS to arrive, as that
would incur a penalty of one RTT, so it was to adopt a default of 4096.

I think that part has been clarified correctly in
https://github.com/httpwg/http2-spec/issues/1003. Thank you for the work.

OTOH, I'm not sure if all the text that went in with #1003 is correct. I'm
not sure if I agree with the interpretation of RFC 7541 requires HPACK
encoders to send Dynamic Table Size Update when the table size is to remain
the same. I am also concerned that the newly added text, that suggests that
endpoints MAY error-close the connection unless peers behave as such, might
increase  interoperability failures, under the assumption that not all
servers behave like that. Please see
https://github.com/httpwg/http2-spec/issues/1004.



> You can add facebook.com and google.com to the "OK" list as well.
>
> These all fail for any setting value that is less than 4096.  4095 causes
> the same error as zero for those servers.  I traced the HPACK instructions
> of a few of these (which is a bit tedious) and it's clear that the Dynamic
> Table Size Update instruction is not being sent by the "broken" servers
> here.  4097 should create a similar error, as none of the servers I checked
> send the instruction then either.
>
> However, nghttp2 only checks for the instruction after a reduction but not
> after an increase.  Many of those servers don't send the Dynamic Table Size
> Update instruction if the size increases.  I don't know what they think the
> header table size *is* at that point, but it is being used, which is not
> great.
>
> None of those servers cause a problem with Firefox with a changed setting
> value, so I guess that Firefox simply doesn't check for the instruction
> being present after the "change" from the initial values, or maybe it
> assumes that the value it sets in its preface is what the table is
> initialized to.  I don't know.
>
> That all said, this looks like a bit of a shambles.  I've no idea what the
> client and server think the header table size is after this exchange.
>
> For haproxy, what would it take to fix the problem?  More importantly
> perhaps, what would it take to get the fix deployed?  I should probably ask
> all the other folks listed here (phk, kazuho, stefan, dmitri) the same
> question.
>
>

-- 
Kazuho Oku