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:

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, this converter 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

• without an email address or

• with an invalid destination email address (when the address is to a mailbox on the same domain that the script is running on).

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