Question

I am using a Perl module called from a CGI scipt in IIS 6 that is bombing. The identical folder structure on an XP machine (IIS 5.1) works fantastic. If I remove the module loading command at line 9, it will print “about to load” and “ok”, but When I try to run

use Language::Guess;

I receive

The specified CGI application
misbehaved by not returning a complete
set of HTTP headers.

in the browser.

The folder structure is
/cgi-bin/test.pl
/PerlModules/Language/Guess.pm

I have tried adjusting the file/folder permissions and have reviewed my IIS configuration time and again. It runs fine from the command line on the IIS machine or if I copy the module into \Perl\site\lib, but I don’t have permission to load modules on the shared server this script is destined for. Am I missing something simple?

Here is test.pl

use strict;
use CGI ':standard';

print header("text/html");

use lib "..\\PerlModules\\"; 
print "about to load<br/>";
#bombs here
use Language::Guess;

print "ok"

Answer 1

The problem is the line

use lib "..\\PerlModules\\";

Change it to the full path to where the Perl modules are:

use lib "C:\\Perl\\PerlModules\\";

or whatever.

Reason is that your CGI script run from the command line in the same directory is OK, but when it is being run with an absolute path by the server from a different directory, the directory ..\\PerlModules\\ is no longer the correct location of the modules (because now .. is relative to the server’s directory, not your script’s). When it tries to load the module, it can’t find it and prints an error message. The web server can’t cope with the error message, so you get the above.

If you don’t want to use the absolute path in your cgi script, investigate using use lib inside a BEGIN block with the FindBin module.

One thing which alleviates this kind of problem is the CGI::Carp module and its “fatalsToBrowser” option:

 use CGI::Carp 'fatalsToBrowser';

catches mistakes & throws them out to the browser. This is for debugging only though.