What To Do About CGI Installation Error Messages
Here are step-by-step rundowns for solving annoying server
error messages you might see when you install a CGI script.
Probably most will be solved at the first or second step.
Others, but very few, may need attention beyond what's
covered in the rundowns.
By far the most common server error message in relation to
CGI scripts is the "Internal Server Error." Others not so
common are "Premature end of script headers" and "...
malformed header from script. Bad header=No recipient
addresses found ..." messages.
All procedures in this article assume a Unix/Linux server.
The "Internal Server Error" Message
Rundown Step 1 —
Verify the script has correct permissions.
Virtually all servers require CGI perl scripts to have 755
permissions. Refresh the directory's listing to ensure
you're looking at the latest information.
This step's solution:
If permissions are anything other than 755, change them.
Should your FTP program not let you change permissions, it
may be the server is configured to disallow it. If yes,
talk to your hosting company about getting the restriction
lifted. If not a server restriction, get a different FTP
program.
Permissions 755 correspond to this table:
| 7 | read/write/execute | Self/Owner |
| 5 | read/execute | Group |
| 5 | read/execute | Global/Other/World |
Rundown Step 2 —
By far the most common reason for this error message is a
file uploading error; the script is uploaded as a binary
file instead of a plain text file.
Different operating systems use different characters or
sets of characters to mark line endings of plain text
files. Windows uses what's called a carriage
return/linefeed combination (ASCII 13 and ASCII 10).
Unix/Linux uses only the linefeed character by itself.
When perl runs a script, it expects the line endings to be
the operating system's standard. If it isn't, the script
breaks with an Internal Server Error.
When an FTP program is used to transfer a file from your
computer to the server, uploading the file as plain text
lets the FTP program convert the line ending characters of
your computer into the line ending characters expected by
your server. Similar with downloading. Uploading or
downloading, the line ending characters can be converted to
what the destination computer expects. (If up/downloaded as
a binary file, the FTP program makes no changes to the
file.)
If you do not use FTP, but use a file uploading web page
interface of some kind, the uploading mechanism might not
convert line endings, or do so incorrectly. In those cases,
the files must have the correct line endings *before*
they're uploaded.
Plain text word processors are available to do those line
ending conversions for you. If only converting one or
several, http://BontragerCGI.com/Line_Endings.html is a
free service that can be used to convert the line endings
of any text file to Unix/Linux line endings.
This step's solution:
Re-upload the script with your FTP program, verifying the
transfer is being done as a plain text file and not as a
binary file. If using a web page interface to upload,
instead of FTP, make sure the file has correct line endings
before uploading.
If that doesn't work, get a new copy of the script and try
again.
If it still doesn't work, go to the next step.
Rundown Step 3 —
If the script was edited (or viewed) with a word processor
that displays or saves files in any way other than
ASCII/plain text, this could be the problem. Such word
processors, for this rundown, include software such as
Word, FrontPage, and other WYSIWYG document or web page
editors. Such software can insert extraneous characters
into the script.
This step's solution:
Grab a new copy of the script and, if editing is required,
do so with NotePad or TexEdit or other plain text word
processor.
Rundown Step 4 —
Verify the first line of the script is correct.
The first two characters of the first line must be: #!
The rest of the line is the location of perl.
There may be no space or lines in front or above the #! and
there may be no spaces at the end of the line.
The two most common locations of perl are
#!/usr/bin/perl
#!/usr/local/bin/perl
Note that "usr" is spelled with 3 letters, not the 4-letter
"user". Typing "user" instead of "usr" is an easy to miss
typographical error.
This step's solution:
Re-type the first line of the script. Preferably, this is
done by copying from a script known to work and pasting
into the current script with the Internal Server Error
issue.
Rundown Step 5 —
Verify the directory where the script is installed has been
configured to run CGI scripts. If other scripts in this
directory (or parent directories) run okay, then this is
not the issue. But if this is the first script for this
directory, it may be prudent to verify with the hosting
company that it is indeed configured to run scripts.
This step's solution:
The hosting company needs to change the domain's
configuration to allow the directory to run scripts.
Rundown Step 6 —
A Perl module that the script uses might not be available
on your server. To determine whether or not this is the
case, look through your script for lines beginning with
the word "use", like:
use _______;
(the underscore being the name of a module). The "use"
statements are usually near the top of the script or
following the user customization area.
You can test your server to see whether or not certain Perl
modules are installed with Master Pre-Installation Tester
This step's solution:
If a module the script uses is not available on your
server, it will need to be installed before the script will
run. Installing modules can be rather technical, so you may
wish to ask your hosting company to do it for you.
Rundown Step 7 —
The path to sendmail may be incorrect. If the script runs
without errors until the point where it would most likely
be sending an email, this may be the reason for the error.
This step's solution:
Correct the path. (The three most common typographical
errors are forgetting the "/" character at the beginning of
the path, spelling "/usr/" as "/user/", and forgetting the
" -t" [space,hyphen,t] at the end.)
Rundown Step 8 —
Verify your script is not trying to send an email
If the script runs without errors until the point where it
would most likely be sending an email, this may be the
reason for the error.
This step's solution:
Provide an email address or correct the email address.
The "Premature end of script headers" Message
I've seen some servers report "Premature end of script
headers" when it was actually an "Internal Server Error."
If the rundown for this message does not get rid of the
error message, consult the "Internal Server Error" message
rundown.
A "Premature end of script headers" error usually means
that the script was trying to send something to the browser
(such as a web page) but the browser wouldn't accept it.
The browser must first be told what is coming (called
header information) and then the data can be sent.
So when a script gives that type of error it can mean the
script is sending data to the browser instead of (for
example) to a file.
Another reason for that error is if the script quits
running before anything was sent to the browser. CGI by
definition must send something to the browser. So if the
script ends prematurely, before it had a chance to talk to
the browser, that will cause a "Premature end of script
headers" error.
Now, the above is rather technical in nature and you
usually don't have to concern yourself with those details.
They are mentioned so you have an understanding of what
situations usually cause this error.
If you have a proven script (not in beta, for example) it
is unlikely that the program code itself is the problem.
Actions for solving the issue causing this error message:
Ensure all directories the script requires are available
and that they have the correct permissions. Directory and
file names are case sensitive.
Ensure all files are in the correct directories. For
example, if an email template is required, make sure you
have put it where the script expects to find it as
described in the installation instructions.
Although its absence would usually spawn a different kind
of error, make sure your server has all the required Perl
modules available. If you need to find out, you can use
Master Pre-Installation Tester
If all of the above are okay, you may want to grab a fresh
copy of the script and start from the beginning. It's rare,
but it's possible transmission during download or upload of
the previous copy corrupted the file.
The "... malformed header ..." Message
The "... malformed header from script. Bad header=No
recipient addresses found ..." error message may result
when the script is trying to email to a destination that
isn't a valid email address. It may also result from trying
to send email without providing an email address.
If your script uses configuration files with email
addresses or if email addresses are hard coded in the
script, verify those are present and correctly formatted.
Also, if your script processes a form, verify that the
field names are spelled correctly, especially the ones
having to do with email addresses. Form field names are
case sensitive.
If a script mails to an email address provided on the form,
that form field should be required to be filled in.
Those are the three most common error messages I've dealt
with during my nine years of providing technical support
for CGI scripts. One of the solutions provided will close
the issue in all but the most unusual circumstances.
Will Bontrager
©Copyright 2006 Bontrager Connection, LLC Bontrager Connection, LLC
Please note:
Articles on this website are presented "as is". However -
If you have a question about a CGI script, HTML, CSS, PHP, or JavaScript
Ask one of our Experts and you'll have your answer!
Click here for details.
