I've been porting my perl web application to as many web servers as possible, trying for cgi or better where better is defined as stable (for well written code) and faster. This has meant fooling around with external fastcgi applications (i have approx 30 stub cgi programs, which tends to exclude the web server controlling fastcgi and also exclude scgi). It's also meant finding another web server (nginx) that apparently has it's own highly experimental version of mod_perl.
So far, successfully ported to nginx (fastcgi), lighttpd (fastcgi), iis (isapi), apache (fastcgi && mod_perl) and apache2 (mod_perl2).
Even though my application is therefore successfully tested on at least these web servers, i can only write packages (msi/rpm/dpkg) for iis and apache(?:2)?. All the others refuse to acknowledge the idea that a writer of a web-application requires a conf.d style directory to place their web server configuration snippet into. And some of these "snippets" can get quite large.
i think it's interesting that, apart from main players, i haven't been able to find a web server whose developers sat down and thought "how are our clients actually going to interact with our program" :)
Re:30 stubs!?
ddick on 2008-04-15T06:21:37
I never really arrived at a yay/nay for that idea. On the one hand, it makes it possible to use fastcgi in more environments and to use scgi. i always thought that it would damage straight cgi as suddenly every url call loads 250K lines of perl instead of maybe 1/10 of that. I just never got round to testing whether or not that assumption was true or not.:)
