mike hal has asked for the wisdom of the Perl Monks concerning the following question:

Hello Again All,

This is a follow-up to this question. However, now I think that I have significantly narrowed the scope of the problem...hopefully :-). The test script below executes fine when run from the command prompt but fails when executed via the web server. 

#!/usr/bin/perl -w

use strict;
use lib qw(the/full/dir/path/8080/cgi-bin/usr/local
    the/full/dir/path/8080/cgi-bin/usr/local/lib/perl5
    the/full/dir/path/8080/cgi-bin/usr/local/bin
    the/full/dir/path/8080/cgi-bin/usr/local/lib/perl5/site_perl
    the/full/dir/path/8080/cgi-bin/usr/local/bin); 

use CGI qw/:standard/;
use HTTP::Request

print header;    
print "TEST SCRIPT\n";
exit;

[download]
The following error is triggered. 
... the CGI program /the/full/dir/path/8080/htdocs/test.cgi did not pr
+oduce a valid header (name without value: got line "compilation faile
+d in require at /the/full/dir/path/8080/cgi-bin/usr/local/lib/perl5/s
+ite_perl/http/request.pm line 14.")

[download]
At first I figured that the user that the web server runs under didn't have permission to read the modules. So I created a symbolic link to the module file (Request.pm) and the module contents displayed in the browser. Any thoughts?

Replies are listed 'Best First'.
Re: Module Compilation Problem (cmd prompt vs. web)
by InfiniteSilence (Curate) on Sep 26, 2005 at 18:56 UTC
    Are you using Apache as your webserver because, in Apache, when you specify a script alias for the cgi-bin directory you can just use relative paths after that (below from httpd.conf): 

    ScriptAlias /cgi-bin/ "C:/wereMyCgiBinBeAt/"

    [download]

    So you can replace the horrid (and non-portable) looking: 

    use lib qw(the/full/dir/path/8080/cgi-bin/usr/local
    the/full/dir/path/8080/cgi-bin/usr/local/lib/perl5
    the/full/dir/path/8080/cgi-bin/usr/local/bin
    the/full/dir/path/8080/cgi-bin/usr/local/lib/perl5/site_perl
    the/full/dir/path/8080/cgi-bin/usr/local/bin);

    [download]
    To: 

    use lib qw(
    /usr/local
    /usr/local/lib/perl5
    /usr/local/bin
    /usr/local/lib/perl5/site_perl
    /usr/local/bin
    );

    [download]

    On a more serious note...do my eyes decieve me or do you have Perl in the cgi-bin directory? Here's a site that thinks that is a bad idea (checked perlsec but didn't find a specific reference to it though).

    Celebrate Intellectual Diversity

[reply]
[d/l]
[select]
Re: Module Compilation Problem (cmd prompt vs. web)
by randyk (Parson) on Sep 27, 2005 at 06:03 UTC
    Perhaps some points for clarification:
    • Does the same script run OK without the use HTTP::Request line? If so, where on your system is the CGI.pm module found? Is it part of the the/full/dir/path/8080/cgi-bin/usr/local tree?
    • What operating system is this on? As was raised in the original question, it's strange that the error in HTTP::Request is reported as http/request.pm. This might suggest there's an issue with case sensitivity and/or tolerance of file names, if this applies to your operating system.
    • The symbolic link you tried was from where to where? Also, when you say the contents were subsequently displayed in the browser, was this the contents of the HTTP::Request module, or of the script? If it was the script, there may be a misconfiguration present in your web server; if it's Apache, see the documents on using CGI for suggestions.
    • Does the path represented by the/full/dir/path/8080/cgi-bin/usr/local represent a full perl installation, including a perl binary? If so, is this perl compatible with the binary specified by #!/usr/bin/perl used to invoke your script? Is it the same perl that was used (successfully) to test the script from the command line?
    As an aside, it probably is a bad idea to have a perl binary beneath the cgi-bin directory, if that is the case; if it's not protected through proper permissions from the outside world, it's not inconceivable that someone might come along and try exploring things like http://your.server/cgi-bin/usr/local/bin/perl, and if they find it ...
[reply]
      Thank you for your detailed questions. I want to apologize in advance if my responses are not on-point. I’m a neophyte still trying to figure out my way around. I have addressed your questions on a point-by-point basis.
      • The script runs runs OK without the use of the HTTP::Request module. HTTP::Request is locally installed within the account home directory specified by the/full/dir/path/8080/cgi-bin/usr/local path. The CGI.pm module is located here: /usr/lib/perl5/5.8.0

        FWIW, here is the @INC value as printed from the script: … 

        /the/full/dir/path/8080/cgi-bin/usr/local<br>
/the/full/dir/path/8080/cgi-bin/usr/local/lib/perl5<br>
/the/full/dir/path/8080/cgi-bin/usr/local/bin<br>
/the/full/dir/path/8080/cgi-bin/usr/local/lib/perl5/site_perl<br>
/the/full/dir/path/8080/cgi-bin/usr/local/lib/perl5/man<br>
/the/full/dir/path/8080/cgi-bin/usr/local/lib/perl5/man/man3<br>
/usr/lib/perl5/5.8.0/i386-linux-thread-multi<br>
/usr/lib/perl5/5.8.0<br>
/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi<br>
/usr/lib/perl5/site_perl/5.8.0<br>
/usr/lib/perl5/site_perl<br>
/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi<br>
/usr/lib/perl5/vendor_perl/5.8.0<br>
/usr/lib/perl5/vendor_perl<br>

        [download]
      • This is an iplanet web server running Linux. I agree with your concern about the case sensitivity issue. However, if I module remove references to other modules within HTTP::Request, the module does not throw an error when run from the web server.
      • The symbolic link: /full/dir/path/8080/ownercenter/gmocus/test.cgi Points to: /full/dir/path/8080/cgi-bin/validator/test.cgi Secondly, the module contents, not the script contents, displayed in the browser
      • No, the path the/full/dir/path/8080/cgi-bin/usr/local only points to those local modules required by the script to perform a specific function.
      • I agree. Once I resolve the current issue, I’ll need to address the various security vulnerabilities.
[reply]
[d/l]
        Based on your @INC, one thing that may be worth checking is the following. HTTP::Request requires HTTP::Message, which in turn potentially requires a number of other modules (one can use scandeps.pl to see which ones). The pure Perl modules such as HTTP::Headers are presumably available under /the/full/dir/path/8080/cgi-bin/usr/local/lib/perl5/site_perl, if not under the system /usr/lib/perl5/ tree, but there's some XS-based modules, such as MIME::Base64 or Compress::Zlib, that may also be needed. Such modules normally get installed into an architecture-specific subdirectory, such as i386-linux-thread-multi. The lib module will add such architecture-specific directories to @INC for you, but they don't seem to be present in your /the/full/dir/path/8080/cgi-bin/usr/local/lib/perl5/site_perl tree. If modules such as MIME::Base64 and Compress::Zlib are not available under the system /usr/lib/perl5/ tree, are they present in your /the/full/dir/path/8080/cgi-bin/usr/local/lib/perl5/site_perl tree? If so, are they in such an architecture-specific directory? If they are available, but in a non-standard location, you may have to add such directories to your use lib statement.
[reply]

Back to Seekers of Perl Wisdom