September 2013 - web-devel

HTTP pipelining and constant space usage?
by Jeremy Shaw 18 Sep '13

18 Sep '13

It seems like HTTP pipelining and constant space usage are at odds with each other. 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. :)

3 3

Sending a Response before the Request has been entirely consumed?
by Jeremy Shaw 18 Sep '13

18 Sep '13

Hello, Is it valid for a server to start sending an HTTP Response before the Request has been entirely consumed? Or to put it differently, is there any case where it would be valid for the Response message-body to be streaming the value from the Request message-body? Doing that seems like it would, in general, not be a good idea. For example, if you started sending a 200 OK response, and then you encountered a parse error in the Request message body, there is no way to go back and change to an error status code. One slight exception seems to be the use of 100 (Continue), section 8.2.3, http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html but even there, you are just looking at the Request headers, not trying to stream from the Request message body to the Response message body. In this section: http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6 It says, "After receiving and interpreting a request message, a server responds with an HTTP response message." Which could be interpreted to mean that the entire request message must be received and interpreted before the response can be sent. But, that could be reading too much into it. I'd rather see something like: "The server MUST read the entire request message before sending a response." Any thoughts? Is there any definitive statement? Are there any real world examples where you would want to stream the request message body into the response? For example, a service where you can PUT/POST a document, and it gets transformed on the fly and returned in the response? At this point I am inclined to design the server such that you must read the entire request message before you can begin sending the response. But, if that is a mistake, I'd love to hear about it now ;) - jeremy

4 5

yesod mysql
by Grant Weyburne 17 Sep '13

17 Sep '13

Hi all, I am trying to use Yesod with Mysql on Windows but cannot get the mysql package to build. I can see that there is an error report about this problem that hasn't been addressed for the past 11 months: https://github.com/bos/mysql/issues/3 At the moment this means that the only real database on Windows is Postgres, but I can only use mysql or mssql in this project. Since it doesn't look like this problem will be solved any time soon, can anyone think of reasonable alternatives? So far my only thought is using an Odbc interface with a subset of the persistent functionality. This could additonally open up access to MS Sql Server and Oracle. Anyway, I'd appreciate your thoughts about this. Thanks so much, Grant

3 4

oops
by Grant Weyburne 16 Sep '13

16 Sep '13

Sorry for the multiple posts, Grant

1 0