Yes, this needs to be fixed. I don't see it as difficult problem. We already test for whether the output filters need to be flushed (i.e., is there any more data in the input filter chain) before the request ends. We just need need to remember the outcome of that test and react appropriately.
This isn't about whether the output filters need to be flushed: this is about whether the connection-level input filters have already read data from the socket and are hanging onto data that needs to be processed before the client will send more data. The event MPM will be sitting on a poll() waiting for the client to send more data when the client already has sent the next request.
Are there a lot of browsers out there that implement true pipelining? I know it's in the RFC for good reasons but I don't believe I've ever seen it in the wild.
Mozilla, Opera, Squid, etc. I'm, uh, absolutely against any code being checked in that breaks HTTP pipelining. (You should get the drift of where I'm going.)
umm, I disagree. I'm not too concerned about worker threads blocking in socket reads occasionally. The point here is to go after the low hanging fruit (frequent long delays between requests) without massive code churn in the server.
Certainly not at the expense of HTTP/1.1-compliance. -- justin
