Adam Langley wrote:

On Sun, Apr 13, 2008 at 4:59 AM, Johan Tibell wrote:

...

* Using a different set of data types would work better.

Give that this is Haskell, I'd suggest more types ;)

HTTP headers aren't just strings and, at the risk of tooting my own horn, I'll point to the Headers structure in [1].

That is one of the things I don't like about Network.HTTP, which also enumerates header fields. It is inconvenient to have to look up the names in the data type, when the standard field names are already known, and it makes using non-RFC2616 headers less convenient. Automatic parsing of header fields also makes unusual usage inconvenient, (for example the Range header support in [1] is a profile of RFC2616.) I think those kinds of features belong in frameworks; they will be more of an annoyance than a help to anyone that is writing to the WSGI layer.

Likewise, URLs have lots of structure that should just be handled in one place [2]

Yes, I think should be parsed to the level of granularity specified by RFC 2616 (i.e. scheme, host, port, path, query string) and anything more (like parsing query strings) should be handled by frameworks.

[1] http://darcs.imperialviolet.org/darcsweb.cgi?r=network-minihttp;a=headblob;f... [2] http://darcs.imperialviolet.org/darcsweb.cgi?r=network-minihttp;a=headblob;f...

AGL

-- Michaeljohn Clement