> Re: HTTP/1.1 is the worst Technically, this could have been mapped with an additional header alone. Something like HTTP/1.2 that features a header like Tran

> Re: HTTP/1.1 is the worst Technically, this could have been mapped with an additional header alone. Something like HTTP/1.2 that features a header like Transfer-Request-Id: 13337 While I agree with the sequential pipelining case I'd argue with the abuse from the other perspective. Clients have now much more power to re-request things in a suboptimal order, because the server still accepts it. There's no cryptographic signatures on buffers that could allow a dictionary on what has been sent already, and what has not, which would fix the issues that a client can re-prioritize and re-request resources that will drain the server. The beauty of HTTP/1.1 (apart from slowloris) was its simplicity and cacheability for reverse proxies. Now with H2 shit can hit the fan real quic once a new LOIC comes out because it has a whole new attack surface for DDoS scenarios, where even a single client can take down a server in those circumstances (aka when a server blindly accepts re prioritization requests). But I would agree that HTTP/1.1 isn't good when it comes to transport hop specific headers (everything Transfer-...) because they allow crafted packets like HTTP smuggling that can trick a reverse proxy and backend because there's no way to validate the packets on a lower level when it comes to their Origin. This is something I would've hoped SPDY/QUIC would address, because they are a real security risk embedded into the nature of the protocol.