[web-devel] Hoogle Advice

[Neil Mitchell]

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