3 ms·

>In the diagram below, request 2 cannot be sent until response 1 arrives, considering that only one TCP connection is used. That's wrong, request 2 can be sent

>In the diagram below, request 2 cannot be sent until response 1 arrives, considering that only one TCP connection is used. That's wrong, request 2 can be sent before response 1 arrives. Blocking is inability to receive response 2 until response 1 arrives. With HTTP/2 responses can be unordered.

tialaramex 3y ago
https://en.wikipedia.org/wiki/HTTP_pipelining https://en.wikipedia.org/wiki/HTTP_pipelining In practice it's not wrong. HTTP 1.x servers, and especially "middleboxes" get this badly enough wrong that when you ship this feature ("HTTP 1 pipelining") your users will report a low but persistent error rate. Oops the password request and image download were kinda sorta fused together. You can (and some very minor browsers do) just insist it's not your bug and then painstakingly reject every incident where this is implicated, or you can just accept that this was never going to work in practice as the document you're disparaging does.
- anonymoushn 3y ago
  Do you get a mostly eliminated error rate if you only use pipelining over TLS, or have server operators situated their defective middleboxes behind their TLS termination?
  - GoblinSlayer 3y ago
    I guess, it's about things like UserGate, they generate MITM certificates on the fly and decrypt traffic. On the other hand, if they can't handle http1, why they would handle http2?
  - pornel 3y ago
    Not really, because broken proxies include anti-virus software that sits at the endpoint, as well as corporate TLS-MITMing boxes. Browsers have spent years trying to find a way to deploy pipelining, but nothing really worked. You can't even allowlist based on known-good User-Agent or Via headers, because the broken proxies are often transparent. It's also very hard to detect pipelining errors, because you don't just get responses out of order, you may get response bodies mangled or interleaved. The idea is truly dead. With H2 being widely supported now, and having superior pipelining in every way, there's no incentive to retry the pain of deossifying H1.
ghusbands 3y ago
To be very clear/direct, the HTTP pipelining you're referring to never fully worked and was always hit with problems with middleboxes, problems with servers, significant security vulnerabilities around request smuggling and more besides. Every project I've been involved with that tried to use them eventually turned them off. So the quote is true in practise.
- GoblinSlayer 3y ago
  AIU request smuggling, it can't be prevented by disabling pipelining, only by validation.

tialaramex 3y ago

https://en.wikipedia.org/wiki/HTTP_pipelining https://en.wikipedia.org/wiki/HTTP_pipelining In practice it's not wrong. HTTP 1.x servers, and especially "middleboxes" get this badly enough wrong that when you ship this feature ("HTTP 1 pipelining") your users will report a low but persistent error rate. Oops the password request and image download were kinda sorta fused together. You can (and some very minor browsers do) just insist it's not your bug and then painstakingly reject every incident where this is implicated, or you can just accept that this was never going to work in practice as the document you're disparaging does.

anonymoushn 3y ago
Do you get a mostly eliminated error rate if you only use pipelining over TLS, or have server operators situated their defective middleboxes behind their TLS termination?
- GoblinSlayer 3y ago
  I guess, it's about things like UserGate, they generate MITM certificates on the fly and decrypt traffic. On the other hand, if they can't handle http1, why they would handle http2?
- pornel 3y ago
  Not really, because broken proxies include anti-virus software that sits at the endpoint, as well as corporate TLS-MITMing boxes. Browsers have spent years trying to find a way to deploy pipelining, but nothing really worked. You can't even allowlist based on known-good User-Agent or Via headers, because the broken proxies are often transparent. It's also very hard to detect pipelining errors, because you don't just get responses out of order, you may get response bodies mangled or interleaved. The idea is truly dead. With H2 being widely supported now, and having superior pipelining in every way, there's no incentive to retry the pain of deossifying H1.

ghusbands 3y ago

To be very clear/direct, the HTTP pipelining you're referring to never fully worked and was always hit with problems with middleboxes, problems with servers, significant security vulnerabilities around request smuggling and more besides. Every project I've been involved with that tried to use them eventually turned them off. So the quote is true in practise.

GoblinSlayer 3y ago
AIU request smuggling, it can't be prevented by disabling pipelining, only by validation.