Majority of the cases were requests that HTTP/2 clearly specified as malformed but they were not treated as such. It's reasonable to expect there will be other

Majority of the cases were requests that HTTP/2 clearly specified as malformed but they were not treated as such. It's reasonable to expect there will be other such implementation vulns that won't stem from HTTP/1 historical baggage - that is just where the author was looking today. So I'm fine with the "HTTP/2 is worse in its own" presumption because it's harder to implement. Then, the \r\n in headers can easily trip an application that was naively ported to http/2 supporting network library. That's too pretty ripe for blame shifting :)