Re: HTTP/2 GREASE, Results, and Implications

[Willy Tarreau <[e-mail]>]

On Fri, Nov 15, 2019 at 11:35:13AM -0800, Tom Bergan wrote:
> 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.

Regardless of these issues, Bence's proposal sounds appealing to me for
a better layering.

> 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.

Oh it's very simple to understand: due to the rules restricting the frame
types depending on the stream state, the frames are matched against the
stream state early during the processing. In fact proceeding as you
suggest would make the code simpler, it's just that it's changing the
logic, and while I do see how to adapt mine for this (with limited risks
of regressions when it comes to backport this to deployed maintenance
branches), it's easily imaginable that and equivalent level of complexity
(not high, just moderate) can affect other deployed implementations,
causing some reluctance to changing existing code in field.

I *am* personally willing to make the change if there is consensus on
this. I even hacked a minimal patch for this after Mike's report. I'm
just not assuming that everyone will do so in an eyeblink.

Another option could be to refrain from sending new frame types until
a setting has been advertised by the other end. I just find this a bit
sad. That's exactly what the minor version in the protocol was for. We
could have had HTTP/2.1 advertised over ALPN to instantly match both
ends, but now we have to do without this possibility.

Willy