On Wed, Sep 18, 2013 at 5:45 PM, Jeremy Shaw <jeremy@n-heptane.com> wrote:
It seems like HTTP pipelining and constant space usage are at odds with each other.

A quick review of 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().

Clients that pipeline need to be aware of this and use IO-multiplexing or separate threads for the read and write sides of the socket.
 
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..

No, you don't read all of the requests, you read them one at a time. Exactly for that reason.

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

In fact, given the way the HTTP spec works, you're right that this is the only sane thing to do.

G
--
Gregory Collins <greg@gregorycollins.net>