- web-devel - Haskell.org

simple-sendfile 0.2.13
by Kazu Yamamoto 10 Oct '13

10 Oct '13

Hi, I have just released simple-sendfile 0.2.13. In this version, I modified the source code for Linux so that I can take profile easier. All tests are passed. Buf if you find something wrong on Linux, please let me know. --Kazu

1 0

http-client library
by Michael Snoyman 04 Oct '13

04 Oct '13

After some discussion with Kazu, I'm planning on starting work on a new package called http-client. The goal will be to separate out the core functionality from http-conduit into a lower-dependency package. In particular, I'm hoping to get a package without dependencies on tls, conduit, or resourcet. The motivations for this are: * Kazu and I need a lighter-weight library for testing out Warp. * With WAI 2.0 coming out, the resourcet-dependent interface of http-conduit currently doesn't make as much sense. * By separating things out like this, I believe we can get clean things up. * The vast majority of the http-conduit codebase has nothing at all to do with TLS or conduit support. Persistent connections, cookie handling, multipart forms, chunking, etc, all fall purely into the realm of raw HTTP support. By getting these core features out there separately, people will be able to take advantage of them without reinventing the wheel. Is there any interest from others in this project? If so, please let me know, as specific requests can help guide the API decisions I make.

2 1

WAI 2.0
by Kazu Yamamoto 03 Oct '13

03 Oct '13

Hi all, I created an issue to discuss WAI 2.0. If you are interested, please join: https://github.com/yesodweb/wai/issues/178 --Kazu

1 0

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

Next version of WAI: cleaning house
by Michael Snoyman 12 Aug '13

12 Aug '13

Some of you may have seen the brief interchange between Kazu and myself regarding ResourceT in WAI. Let me give a very brief synopsis of the situation: - In order to allow WAI applications to acquire scarce resources like file handles in an exception-safe way, WAI actions all live in a `ResourceT IO` monad, instead of just `IO`. - Kazu has mentioned to me in the past that, based on his profiling, monadic bind for ResourceT may currently be a bottleneck in WAI. - I made an experimental change to WAI so that, instead of actions living in `ResourceT IO`, the WAI Request value contains a ResourceT InternalState value, which can be used to accomplish the exact same thing as living in ResourceT (see [1]). - Kazu checked out the performance difference of this new branch, and it allows for some better optimizations. If this was purely a performance optimization, I would probably just optimize Warp and not bother changing WAI. However, I think that this change makes WAI itself better as well, and therefore am in favor of making this as a breaking change, releasing it as WAI 2.0[2]. Firstly, are there any objections to this move? So as long as we're making a breaking change, the question arises: what other changes should we be making to WAI? I know Kazu had mentioned adding fields to avoid the need for lookups, can you clarify that request a bit? Here are some other changes I can think of: - Remove the deprecated isSecure field from the Request data type. - Remove the misleading fields serverName and serverPort fields as well. - Possibly: hide the Request constructor so that new fields can be added without breaking backwards compatibility. If anyone else has some ideas, please bring them up. [1] http://haddocks.fpcomplete.com/fp/7.4.2/20130704-120/resourcet/Control-Mona… [2] For the Yesod community: the change is minor enough that Yesod 1.2 can have some conditional compilation to support both the current WAI 1.4 and WAI 2.0, so this shouldn't affect most Yesod users at all.

9 31

witty v0.0.0 has been release
by Kazu Yamamoto 01 Aug '13

01 Aug '13

Hi all, To demonstrate the bottlenecks of GHC, I have released "witty", a simple network server. If you specify command line options, "witty" uses ideas to overcome the bottlenecks. I hope we can use "witty" to convince ourselves of the problems and discuss how to fix them. You can install "witty" by % cabal update; cabal install witty For more information, please read: https://github.com/kazu-yamamoto/witty/blob/master/README.md --Kazu

1 0

Re: [web-devel] [Yesod] Next version of WAI: cleaning house
by Greg Weber 25 Jul '13

25 Jul '13

When a request hits a handler, it will already have gone through the middleware, so it only seems possible to alter how the response is handled at that point. If you want different middleware for different routes, that is something that must be handled at the routing level, so it seems out of the scope of WAI. But if you explain your use case on the Yesod mail list we can try and come up with a more convenient solution. I do have a WAI middleware that checks routes that might benefit from this. On Thu, Jul 25, 2013 at 10:20 AM, Robert Lee <robert.lee(a)chicago.vc> wrote: > Is it possible in the present design to change middleware modules at the > level of a handler? > > On Tue, 2013-07-23 at 13:04 +0300, Michael Snoyman wrote: > > Some of you may have seen the brief interchange between Kazu and > > myself regarding ResourceT in WAI. Let me give a very brief synopsis > > of the situation: > > * In order to allow WAI applications to acquire scarce resources > > like file handles in an exception-safe way, WAI actions all > > live > > > -- > You received this message because you are subscribed to the Google Groups > "Yesod Web Framework" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to yesodweb+unsubscribe(a)googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > >

1 0