Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

ddick (5726)

ddick
  (email not shown publicly)

I'm based out of Melbourne, Australia. I attend the excellent melbourne.pm.org meetings whenever i get the chance, which is not often enough.

Journal of ddick (5726)

Monday April 14, 2008
06:55 PM

web server interfaces and the importance of conf.d

[ #36152 ]

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" :)

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • CGI::Application::Dispatch is the way to go.
    • 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. :)