Hello Willy,
On Sat, 1 Sep 2018 at 21:00, Willy Tarreau <[email protected]> wrote: > I wanted to address it but the CONTINUATION frame is the worst design > mistake of the H2 protocol and results in layering violations which > make it particularly problematic to implement. In short, while all > frames are independant on each other, this one must absolutely appear > after an existing HEADERS frame and requires to maintain a huge state > of unparsed data to feed to the HPACK decompressor at once after > reassembly. It's even documented in the spec that it can be the source > of a DoS... I see, that's about the same nightmare as IPv4 fragmentation, where supposedly completely stateful routers have to reassemble the IPv4 fragments on MTU mismatched interfaces or to make L4 ACL's actually match the packets. Rethinking about this I don't actually think there a lot of other corner cases triggering CONTINUATION, other than the Chrome 49 case. > And that's sad. It would have been better if most didn't implement this > crap, to get rid of the non-legitimate use cases once for all :-/ > > I will probably revisit this point after 1.9, at least for protocol > completeness, maybe with an option such as > "waste-memory-and-cpu-to-support-stupid-h2-continuation-frames" or > something as explicit to save people from enabling them by accident :-/ Ok. I think with OpenSSL 1.1.1 we may be able to configure ALPN differently for RSA vs ECC certificates (of the same hostname), so by not enabling h2 on RSA certificates, we basically disable H2 for Chrome on Windows XP (Chrome using Microsoft's schannel supporting only RSA on XP). Chrome on Windows Vista would still be broken (as schannel on Vista supports ECC certificates), but the market share of Vista is probably negligible. This should help those that cannot break this unsupported browser/OS combination and still want to use H2. It's just a theory though at the moment, I need to test it. Regards, Lukas
