httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Smith" <>
Subject Re: [users@httpd] pl script error
Date Thu, 16 Jan 2003 14:52:21 GMT
I'll will endeavour to check all that you have suggested before I say, I'm
sure I've checked that before... I've learned that you can miss the most
obvious things and be adamant that it's fine. ;)

Thank you for your time and help and will let you know how it goes.

BTW, I output headers as follows and haven't (as yet) had a problem. I
always make sure that there is a return after the content-type line as well.

print <<"HTML";
Content-type: text/html




----- Original Message -----
From: "Boyle Owen" <>
To: "Kevin Smith" <>
Sent: Thursday, January 16, 2003 2:31 PM
Subject: RE: [users@httpd] pl script error

>-----Original Message-----
>From: Kevin Smith []
>I've just decided to try and run a simple Perl script throught
>the browser
>and it works!  So, why doesn't more complicated perl scripts run, they
>execute on the CLI perfectly everytime.

There are two common problems with CGIs:

- path to perl is wrong. This gives the "file not found" type of error.
If you're convinced that is not a problem, let's forget about that
(although you listed it earlier).

- you don't output a proper header before *any* other data. The is the
"premature end of script headers" error. Note that any other failure
will inevitable trigger this one as well.

This is a bit trickier to spot since from the command line, the script
will run perfectly. You have to know that it should produce a header
first and notice that it is missing. Just to make sure you understand
what's expected, you should have in your script:

print "Content-type: text/html\n\n";

alternatively, with, you can do:

use CGI;
my $cgi = new CGI;
print $cgi->header();

If you haven't got either of these recipes in your script, it'll work
fine as a stand-alone program but fail miserably as a CGI.

If you're convinced it's neither of these then remember that a CGI runs
in a restricted shell (no environement variables are set) and with the
privileges of the apache "User". This might be quite a different
environment from your login shell. This is especially true if the CGI is
reading or writing to files - are you sure CGI has all the ENVs and
paths and perms it needs?

Also, watch that, if you have a multi-server environment, you are not
testing the scripts on one machine but executing the CGI on a different
server (i.e. webserver) where paths and contents of libs, /usr/local/bin
etc. might be different.


Owen Boyle

This message is for the named person's use only. It may contain
confidential, proprietary or legally privileged information. No
confidentiality or privilege is waived or lost by any mistransmission.
If you receive this message in error, please notify the sender urgently
and then immediately delete the message and any copies of it from your
system. Please also immediately destroy any hardcopies of the message.
You must not, directly or indirectly, use, disclose, distribute, print,
or copy any part of this message if you are not the intended recipient.
The sender’s company reserves the right to monitor all e-mail
communications through their networks. Any views expressed in this
message are those of the individual sender, except where the message
states otherwise and the sender is authorised to state them to be the
views of the sender’s company.

The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:> for more info.
To unsubscribe, e-mail:
   "   from the digest:
For additional commands, e-mail:

View raw message