lighter alternative to CGI.pm

[perrin]

I'm helping out with a project that is using Perl from server-side includes on an NT box running IIS. (Yes, it sounds crazy to me too.) The project has hit some performance problems, and it seems to be partly because of the time spent compiling CGI.pm on every request. I'm looking at replacing CGI.pm with an alternative, less bloated module.

The script only needs to parse form variables, parse cookies, and determine its URL. It looks like CGI_Lite can do all that. Is that the preferred replacement for CGI.pm these days, or is there something else I should be looking at? (Remember, it has to work on IIS.)

[Ovid]

Perhaps you can check out CGI::Simple. It loads and runs much quicker than CGI. tachyon appears to have written a nice alternative that is a drop-in replacement for CGI.pm. You can read a comparison at http://search.cpan.org/src/JFREEMAN/Cgi-Simple-0.04/cgi-simple_vs_cgi-pm.html.

Also, are you using ISAPI, or is IIS relying on the file association to load Perl? If the latter, you may wish to switch to ISAPI for improved performance, but you'll lose taint checking.

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

[perrin]

Thanks. I don't suppose anyone has ever compared CGI::Simple to CGI_Lite?

The server is using the ISAPI Perl DLL. Taint-checking? I wish. This is someone else's legacy code, and it doesn't even use strict. I'm hacking out my own little island of clean code in the middle of it, with hopes of eventually expanding to conquer the rest.

[Ovid]

I'm not aware of any comparisons. I like CGI::Simple because it's a drop-in replacement. Converting your code will be ridiculously simple. Since CGI_Lite does not share the same interface you have a longer conversion time and a greater likelyhood of bugs.

One feature of CGI_Lite that you have to contend with is the setting of the OS type to determine line endings with file uploads. If someone simply hardcodes the OS in there, you now have non-portable code.

I just took a look at the CGI_Lite code and spotted a bug. The separator for query strings is defined in the module as an ampersand. It should also support a semi-colon as that's the recommended separator -- though I confess that few use it.

I also noticed that the CGI_Lite::is_dangerous() method skips the null byte. Oh wait! It's not even a method, it's a function, so you can't subclass it. If you need to subclass it (though it sounds like you don't), you'd have to reimplement all of the functions in there that don't pass $self as the first argument.

All in all, CGI_Lite looks like a nice module, but I see some issues with it that could stand some fixing.

Cheers,
Ovid

Update: I just noticed that the is_dangerous function also explicitly returns a zero for false. While I think it's clear that this is to be called in a scalar or boolean contect, if someone were to accidentally assign the results to an array, the array would automatically evaluate as true. Boolean responses should have a bare return for false, but now I think I'm just getting picky. It still appears to be a very useful module.

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

[archen]

Thanks for the info on CGI::Simple! As someone who never uses the HTML side of CGI, this is perfect for a lot of projects I'm working on.
Okay, that's offtopic enough =P

[fglock]

I've used fast-cgi with IIS for a year, without problems.

More info in http://www.caraveo.com/fastcgi/ and http://www.fastcgi.com.

[perrin]

Not exactly an answer to my question, but an interesting thought nonetheless. Thanks for the suggestion.

[tstock]

If it's such a small script, all you need is the functionality described, and performance is an issue, it would probably help not asking the OS to open another file. I am all for modularity, but it seems in your case (NTFS, NT, IIS, CGI, Perl) a little copy-paste modularity might help.

tiago
PS: reader, whenever you feel someone you work with made a technical decision so bad to the point of being comical, please think back to this post. You are not alone...

[dws]

I'm helping out with a project that is using Perl from server-side includes on an NT box running IIS.

Damn. You're probably really close to being able to invert the structure, and turn the HTML into a template. But that won't help your performance issue unless you can run mod_perl.

Is this something you could use PerlScript for? You'd be getting some Cookie- and form-handling for free, and might be able to avoid CGI.pm (or a lighter alternative) entirely.

The Perl-Win32-ASP FAQ has details.

[perrin]

There are a few thousand .htm files using this SSI approach, and changing them all to .asp would be a big deal here. They're URLs that have existed for a long time and shouldn't be changed if possible.

How I long for the flexibility of Apache right now...

[gav^]

I've had good luck with ActiveState's Perl for ISAPI which comes with ActivePerl. This tends to speed things up a whole lot.

We did try out PerlEx on a recent project that had to run on IIS and it was amazingly quick. Definatly worth the money.

Hope this helps...

gav^

[diakonos]

CGI Lite will probably be the closest replacement (with less headache) to CGI.pm but definately not as robust. If there was anyway possible to move to Apache webserver then by all means perl_mod would probably do the trick.

My two cents are wheat pennies.

Good Day!

[perrin]

Naturally if I had that kind of control, we would be using Apache/mod_perl. However, I don't, so I have to find a solution that fits in the existing system. Thanks for the ++ on CGI_Lite.

[diakonos]

Geez! I menat to say mod_perl!!! I have to quit thinking that preview is for layout only. Sorry.

[Anonymous Monk]

Take a look to CGI::Minimal

[Vennis]

I personnally wouldn't use the next code and strongly advice to create a better running server...

But, FYI, you can parse the parameters manually. Depending on the complexity, you could use this.

If you use this 'wannahave a Big Ball of Mud solution' (i love that name) make sure you check the parameters for security problems.

my $input;
if ($ENV{REQUEST_METHOD} eq 'GET'){
    $input = $ENV{QUERY_STRING}; 
} else {
    read(STDIN,$input,$ENV{CONTENT_LENGTH}); 
}
foreach( split(/&/,$input)){
    $_ =~ tr/+/ /;
    my ($name,$value) = split(/=/,$_,2);
    $name =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C",hex($1))/eg;
    $value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C",hex($1))/eg;
    if($param{$name}) {
        $param{$name}.= ",$value"; 
    } else {
        $param{$name} = $value; 
    }
    print "Found $name = $value\n";
}

[perrin]

There's really no need to resort to that. Using a properly coded module does not add significant overhead. Replacing CGI with CGI_Lite turned out to improve overall performance of the script by 60%.