W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2021

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

From: Willy Tarreau <w@1wt.eu>
Date: Thu, 23 Dec 2021 09:02:44 +0100
To: Martin Thomson <mt@lowentropy.net>
Cc: ietf-http-wg@w3.org
Message-ID: <20211223080244.GB10100@1wt.eu>
On Thu, Dec 23, 2021 at 07:33:15AM +0100, Willy Tarreau wrote:
> Yes I know, that's delicate. But we're not changing the spec, just clarifying
> something that seems to match a consensus between a majority of implementers.
> In any case we're certainly not going to declare them non-compliant after
> so many years, whatever side they're currently on. And those who read it
> like me (apparently Cory and Hervé did) will likely not have a big
> difficulty seeing the other interpretation that most other implementation
> already adopted.

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

It even seems to me that it's 50/50 between the two interpretations :-(

Thus it seems to me that we have to be extremely careful about what we
state and that a discussion with the various implementers is needed.
Maybe at least the proposed added note for h2bis could be turned as
a warning about known existing deployments that act differently and
that need to be taken care of.

Received on Thursday, 23 December 2021 08:03:05 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 23 December 2021 08:03:06 UTC