April 2008 - web-devel

Re: [Haskell-cafe] Re: RFC: A standardized interface between web servers and applications or frameworks (ala WSGI)
by Michaeljohn Clement 13 Apr '08

13 Apr '08

Adam Langley wrote: > On Sun, Apr 13, 2008 at 4:59 AM, Johan Tibell <johan.tibell(a)gmail.com> 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;… > [2] http://darcs.imperialviolet.org/darcsweb.cgi?r=network-minihttp;a=headblob;… > > > AGL > -- Michaeljohn Clement

1 0

RFC: A standardized interface between web servers and applications or frameworks (ala WSGI)
by Johan Tibell 13 Apr '08

13 Apr '08

Good day hackers, The Python community have been successful in standardizing an interface between web server and applications or frameworks resulting in users having more control over their web stack by being able to pick frameworks independently from web servers, and vice versa. I propose we try to do the same for Haskell. I've written half a draft for a Haskell version of Python's PEP 333 [1]. If you're interested in taking part in this effort please read through the Python spec first (as it is way more complete and you can understand this proposal better by reading it, I've skipped some important issues in my first draft) and then go read the Haskell spec [2]. I'm particularly interesting in feedback regarding: * Doing in this way won't work as it violates HTTP/CGI spec part X, Y and Z (the Python spec takes lots of things from the CGI spec including naming and semantics). * My server/framework could never provide/be run under this interface. * This interface has bad performance by design. * Using a different set of data types would work better. The spec needs to be extended to cover all the corners of HTTP. Some parts need to be motivated better. It is easier for me to motivate things if people would tell me what parts are badly motivated. Note: I'm open to a complete rewrite if needed. I'm not wedded to the current design and/or wording. In fact parts of the wording is borrowed from the Python spec. The parts with bad grammar are all mine. 1. http://www.python.org/dev/peps/pep-0333/ 2. http://www.haskell.org/haskellwiki/WebApplicationInterface -- Johan

3 2

Re: RFC: A standardized interface between web servers and applications or frameworks (ala WSGI)
by Daniel McAllansmith 13 Apr '08

13 Apr '08

On Mon, 14 Apr 2008 11:06:43 Adam Langley wrote: > On Sun, Apr 13, 2008 at 4:59 AM, Johan Tibell <johan.tibell(a)gmail.com> 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]. And it could go further. The use of a given header is often valid only in certain requests or responses. Perhaps sprinkling some phantom types or type classes around could represent that. Daniel

1 0