On Thu, Feb 19, 2009 at 10:47 PM, Manlio Perillo wrote:

Johan Tibell ha scritto:

...

I haven't given the WAI specification much attention since I first wrote it. Mostly because I'm caught up in thinking about enumerators and their role in e.g. an HTTP server implementation.

Do you have any result?

Yes and no. Hyena used to mix imperative and iteratee style code internally, making the code hard to work with and certain HTTP features hard to implement correctly. It now uses iteratees everywhere. This makes for a more robust and easily extensible implementation. To give you an example I had a hard time implementing pipelining using the old implementation. That should be much easier now. I still don't know iteratees place in the grand scheme of things. I don't even know what's a general, well performing and easily graspable definition would look like! In summary: I have *a* definition of iteratees that works. I just don't know if there's a better one. Cheers, Johan

Johan Tibell ha scritto:

Hi Manlio,

Thanks for reporting the bugs and sorry for the late reply.

On Sun, Feb 8, 2009 at 5:21 PM, Manlio Perillo wrote:

...

I'm trying to compile the example WAI application, as defined in http://www.haskell.org/haskellwiki/WebApplicationInterface

However there are several bugs.

I haven't given the WAI specification much attention since I first wrote it.

I have noted that there is a WAI module in your Hyena web application server. http://github.com/tibbe/hyena I think that, instead, WAI should be defined in a separate package, that should contain: 1) WAI specification 2) WAI data types (hyena.Network.Wai.hs) 3) Some utility functions (see Python wsgiref module) 4) Standard implementation for CGI Since Haskell is not Python, it is necessary that both gateways and applpications use the same data types. Then, in separate packages, it is possible to implement support for SCGI, FastCGI and a simple HTTP 1.0 server (a full HTTP 1.1 server is not a priority, IMHO). IMHO, the WAI (or a separate) package should also contain support for parsing HTTP headers (to be used my both servers, gateways and applications). If there is a thing I hate, is when every project reinvent the wheel. One last note. I have some doubts about the name WAI. It means "Web application interface", but I think that the word "Gateway" should appear in it. Something like: HSGI ("Haskell Server Gataway Interface", that can also be read as "HTTP Server Gataway Interface"), or simply HGI ("Haskell Gateway Interface"). Manlio

On 2009-02-21 12:23 +0100 (Sat), Johan Tibell wrote:

On Fri, Feb 20, 2009 at 3:17 PM, Manlio Perillo wrote:

...

I have some doubts about the name WAI. It means "Web application interface", but I think that the word "Gateway" should appear in it.

I don't have a strong attachment to the name. I'm not sure what the word "gateway" means in this context, probably because I haven't studied CGI in depth.

It's fairly meaningless. CGI stands for "common gateway interface," and is basically: * a web server invoking another program, * with a specifically defined set of environment variables set to various values related to the request and the program's location in the filesystem, * communicating further information via sending it to the program's stdin, and * receiving a header and body response on the other end of the program's stdout, which it then may process before returning it to the HTTP client. There are some further tricks here: if you want to avoid having the server parse and possibly modify the header you send back, you should start your program's name with "nph-". It's generally not possible to reconstruct the original HTTP request that generated the CGI request because various things in the environment variables change based on the configuration of the server, which the client generally has no way of knowing. Even how the various bits of the request are converted to envrionment variables is not very well defined. All these issues translate to FastCGI and SCGI as well, with the addition that the the "programs" don't always have names, meaning that you can't prefix the name with "nph-" to avoid the headers in your response being parsed and modified. I've spent more time than I care to over the last four or five years dealing with FastCGI on the application (i.e., opposite of web server) side, both as a client of existing libraries and a writer of new ones, and it's caused me much pain. The one real advantage that FastCGI has is that it's supported across a lot of web servers, and some have some nice special features. For example, with lighttpd, you can avoid a lot of shoveling of data around by returning an "x-send-file: /some/path" header and no body; lighttpd will then efficently use sendfile or a similar system call to send that file across the network, avoiding a lot of interprocess I/O for large files. (We use this in our QWeb framework for our "docroot" servlet, which just serves files from disk, and also for servlets where we're sending the cached copy of previously generated content.) But overall, I'd be much happier with a protocol that just handed me the raw HTTP request, and allowed me to send back a raw HTTP response. The issue is, of course, getting the protocol implemented in various web servers. I could, I suppose, design a new protocol and write a C implementation for lighttpd. But then, given that I'd hope to be talking to a Haskell application server anyway, GHC has great support for building efficient, multiprocessing, highly concurrent servers, and Haskell is about a hundred times nicer to program in than C, I think I'd just write a high-performance web server in Haskell. (Except that it's already been done, anyway.) Oh, right, where does "gateway" come in? Nowhere, really. Perhaps the word came from someone steeped in the days of MS-DOS BBSs (I ran one myself in the early '90s), many of which had "doors," which were programs to which control would be handed from the BBS software, with the BBS software doing some tricks to take care of the I/O over the modem, a la RCP/M. (That stood for "Remote CP/M," a system so old that Wikipedia doesn't even have an entry for it.) cjs -- Curt Sampson +81 90 7737 2974 Functional programming in all senses of the word: http://www.starling-software.com

Thanks for the explanation Curt! On Sat, Feb 21, 2009 at 1:00 PM, Curt Sampson wrote:

But overall, I'd be much happier with a protocol that just handed me the raw HTTP request, and allowed me to send back a raw HTTP response. The issue is, of course, getting the protocol implemented in various web servers. I could, I suppose, design a new protocol and write a C implementation for lighttpd. But then, given that I'd hope to be talking to a Haskell application server anyway, GHC has great support for building efficient, multiprocessing, highly concurrent servers, and Haskell is about a hundred times nicer to program in than C, I think I'd just write a high-performance web server in Haskell. (Except that it's already been done, anyway.)

I'm currently experimenting with such an HTTP request data type in the context of Hyena, my web application server. I'll post a message to this list once I have something to share. Cheers, Johan