A quick review of HTTP pipelining,

http://en.wikipedia.org/wiki/HTTP_pipelining

Handling persistent HTTP connections is no big deal, but HTTP pipelining is troublesome (which is why Opera is the only browser that has it enabled by default).

The problem is that the client is allowed to send an unlimited number of Requests before it bothers to read any Responses.

If your server uses the model of read a single Request and send the Response entirely before moving onto the next Request, then you could potentially deadlock because the client is still in the sending phase and you are blocked on a write().

So, we are basically forced to read all the Requests before sending a Response? But, then the client could perform a DoS by sending millions of requests..

Any thoughts on how best to handle this?

Perhaps the only sane solution is to assume that any client that is going to using pipelining is going to be nice enough to actually read Responses even if it is still sending additional Requests (i.e., it has a writer thread and a reader thread)? In which case we can continue to read and respond to one request at a time[1]? I'm pretty sure this is what all the Haskell HTTP servers do at the moment and I have not heard any complaints...

- jeremy

[1] In theory, the server could processes multiple Requests in parallel as long as it returns the Responses in the correct order. Though it's not clear if this would actually help performance in most cases. Given the lack of pipelining support in clients anyway, it's nothing something I am especially interested in optimizing. :)