Hi Michael,
1) Why not add statusOK as an alias for status200?
The main reason I stuck with numerical values was the redirects: there is a bit of ambiguity about the right name for 302, 303 and 307. (Yes, I know that the specs give a name for these, but in practice they are treated slightly different.) Frankly, I had always intended WAI to be something low-level that a framework would wrap around. It's a new phenomenon that there is interest in writing directly against WAI.
I think WAI could be increasingly used - its at a level of abstraction that I quite like. I certainly have other projects which I will probably switch over to WAI/Warp.
2) Changing from HTTP to Wai, it was a shame that I had to define all the header keys myself - could they be included - it would have better performance, and give static guarantees. I added locally:
hdrContentType = mkCIByteString "Content-Type" hdrCacheControl = mkCIByteString "Cache-Control"
Firstly, CIByteString is an instance of IsString, so you can just write "Content-Type".
My main concern is the static safety. I know about fromString, and could write "Content-Type", but I could equally write "Contont-Type" and never notice. I realise there is an issue with adding lots of headers, and there are always more headers, so I'm happy to leave the 4 or so I send defined locally.
4) I defined a Wai handler that threw an error, and Warp did nothing. Should it? Or should I just be careful and include my own exception handling? I'm not really sure what the right thing to do is - silently eating the error isn't great, but bring down my server would be even less appreciated.
There's already a request in place to allow you to provide a callback function for exceptions. However, I personally prefer having the application catch all exceptions (which is what Yesod does in practice).
I'm not overly fussed - in my custom web server I just printed exceptions to stdout, but that's probably not a great idea for a more general server.
You could probably write something simpler using the consume iteratee from the enumerator package. It's late at night here, so the following may or may not fire missiles:
responseEnumerator r $ \s hs -> do builders <- consume return (s, hs, Blaze.toLazyByteString $ mconcat builders)
That looks much simpler. Is there any chance of adding some operation like responseFlatten to WAI? It nicely mirrors the responseLBS, and would make it very easy to transition from HTTP - although it's easy enough to write this function locally.
above function. However, outputting a response in CGI format is trivial, and is probably the easiest way to debug/view the contents of
I think such a function would make more sense for the wai-extra package. I already have a debug middleware over there, that kind of function could be a good addition.
wai-extra introduces the zlib-bindings dependency, so I wouldn't make use of it in wai-extra, given it's just for CGI output, and I'm not intending anyone to use CGI. But it would be a useful function to be around, and I may want to use the gzip middleware at some point anyway, in which case I would use it.
Builders. You'll probably be best off mconcat'ing your Builders into a single Builder, converting that to a lazy ByteString and performing the conversion there.
Thanks, with your far cleaner flattenResponse code I feel far less dirty switching back to a bytestring.
In ghci on Windows, running the network function accept doesn't terminate if you hit Ctrl+C. If you run Warp in the main thread ghci will never respond to you again.
I've also been using Warp for development purposes at work on my Windows machine, and have run into the Ctrl-C issue. I'll review this patch after some sleep. My initial reaction is to include it conditionally for Windows. My guess is that very few people (if any) are planning on running production websites using Windows/Warp, so adding something which enhanced usability at the expense of a few cycles would be a general win. However, for the speed-crazed masses serving from Linux (eg, you and me apparently), I'd like to avoid any extra code.
I'm a big fan of keeping Windows and Linux code as identical as possible, but am happy as long as it works. I can't imagine forking a single thread at startup would harm performance at all, but don't mind either way. Thanks, Neil