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

Re: HTTP/2 GREASE, Results, and Implications

From: Tom Bergan <tombergan@chromium.org>
Date: Fri, 15 Nov 2019 11:35:13 -0800
Message-ID: <CA+3+x5GNnHn-MyYO0cDhc6ma1A4CfJMTZ5KBV+ifD5VYkj6brA@mail.gmail.com>
To: Willy Tarreau <w@1wt.eu>
Cc: Bence Béky <bnc@chromium.org>, Stefan Eissing <stefan.eissing@greenbytes.de>, Mike Bishop <mbishop@evequefou.be>, HTTP Working Group <ietf-http-wg@w3.org>
On Fri, Nov 15, 2019 at 7:59 AM Willy Tarreau <w@1wt.eu> wrote:

> I do have a real concern regarding
> deployed code now based on the fact that the way this ambiguity is present
> can have caused solid roots to be set inside some software. For example
> when trying to address the issue in haproxy, I noticed that we've used
> bit fields of permitted frame types to more easily match what's allowed
> or not. When working around them I figured that changing tests constructed
> this way to think in terms of exclusion instead wasn't always as riskfree
> as I initially imagined, and if we relax certain rules we need to be sure
> that (almost) all implementations will accept to revisit their code and
> take such risks in maintenance versions to allow smooth updates of deployed
> components, or we really risk the same type of fragmentation that we've
> known with HTTP/1.1.

It's important to work through these implementation issues. If
implementations are difficult to change, then we'll probably need to take
Bence's suggestion, or something similar.

That said, I don't fully understand the problem here. Can you elaborate?
Assuming the implementation throws away unknown frames immediately, as
suggested by Section 5.5, only the known frames are left. At that point, it
shouldn't matter whether the bit mask describes permitted frames or
forbidden frames -- both approaches are equivalent. FWIW, the Go H2 library
and Chrome both "throw away unknown frames immediately" (although Chrome
has a small bug; crbug.com/1025311).

> But I still do have some concerns about our ability to extend the
> protocol even without this. What if a new frame expects an ACK for
> example ? Probably this one will also require an extension.

I agree. If a new frame type requires an ACK, that needs to be negotiated.
Received on Friday, 15 November 2019 19:35:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:43 UTC