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

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

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.

Received on Thursday, 23 December 2021 23:38:44 UTC