|
|
|
|
|
|
by X-Istence
1331 days ago
|
|
|
You are conflating keep alive with http pipelining, they are not one and the same. Keep alive may be supported and servers may claim to have fully parses request 1 correctly so they can be fairly confident request 2 can be parsed correctly, but reading the spec one way or another and that is no longer a guarantee that holds. Keep alive and http pipelining are supported by major servers, some with bugs or issues, but no clients pipeline requests (at least not the major browsers, curl and other popular tooling). It’s not FUD, pipelining and reuse of an existing connection is broken in the face of trying to parse text protocols that don’t have well defined semantics and where implementations reading the same documentation provide different results because it’s not black and white, it’s fuzzy around the edges. |
|
|
Pipelining is just normal usage of TCP, which is a mechanism to establish two queues of bytes between two endpoints on a network.
There is no difference between sending data before or after having received data from the other party. The two directions are logically independent, even if at the transport level data from one direction contains acks of the other direction.
Now, some servers will start processing requests on a given connection in parallel, and will not correctly synchronize the multiple threads trying to write back their respective response to the client. This is just a bug on the server doing multithreading incorrectly, and has nothing to do with any framing problems in the protocol.
I suppose HTTP/2 supports that use case better, since it can multiplex the concurrent responses, but the correct thing to do is to simply treat each request synchronously one after the other, and not parallelize the processing of multiple requests on a given TCP connection.