Yes, it is weird that a broken protocol translator results in blame for the newer protocol.
As far as I can tell, the article doesn't attack HTTP2, that seems work fine. The article clearly demonstrates the problems of HTTP1. But the real problem is sloppy HTTP2 forntends that generate broken HTTP1.
> Yes, it is weird that a broken protocol translator results in blame for the newer protocol.
From a look at the HTTP/2 spec. this protocol translation is an expected use case and explicitly results in several restrictions on the contents of HTTP/2 headers. So going by the HTTP/2 spec. at least some of those headers should have been rejected by a conformant front end and never made it into HTTP/1.
So how is a collection of broken translators the fault of HTTP/2? The title says 'The Sequel is Always Worse'. It is not HTTP/2 that is bad. It is translation to the, from a security point of view, problematic HTTP/1 that is the problem.
> It is translation to the, from a security point of view, problematic HTTP/1 that is the problem.
Parts of the HTTP/2 spec. specify what malformed headers look like, so this bug is almost entirely in the code not validating those HTTP/2 headers. This also isn't something that a few high school dropouts got wrong on their side projects, several major services got it wrong. Given that the spec. made at least some attempts to warn its implementers maybe future standards need a security section titled "Important: Why ignoring security advisory in standards is a bad idea".
As far as I can tell, the article doesn't attack HTTP2, that seems work fine. The article clearly demonstrates the problems of HTTP1. But the real problem is sloppy HTTP2 forntends that generate broken HTTP1.