3 ms·

HTTP/1.1 has _sequential_ pipelining,its the worst. Reponses need to be sent in the order the requests were made, since there is no _request id_ for the client

HTTP/1.1 has _sequential_ pipelining,its the worst. Reponses need to be sent in the order the requests were made, since there is no _request id_ for the client to know which response is for which request. This is a major annoyance with HTTP/1.1 pipelining, since it then becomes the client responsibility to send requests in an order that minimizes latency. Say you want to retrieve 1) a huge background image of the website and 2) a small js script at page load time. If you send 1) then 2), you have to wait for the background image to come first. Not only this is bad for client user experience, but it also means that the server cannot send responses in real-time, it has to buffer all subsequent responses until the previous ones are sent, creating bloat. HTTP/1.1 is the worst.

cookiengineer 5y ago
> 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.
kaetemi 5y ago
If I'm doing any sort of streaming (video chunks, etc.), then I'd want sequential pipelining for an optimal experience.

cookiengineer 5y ago

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

kaetemi 5y ago

If I'm doing any sort of streaming (video chunks, etc.), then I'd want sequential pipelining for an optimal experience.