Meaning of Common CGI Error Messages:

Error 500

Messages reporting 'Error 500' or server errors can be caused by a number of possible problems. This section briefly lists and explains some of the most common causes of such errors.

Execute permissions not set correctly
For a script to run, the permissions bits must be set to allow it to be executed. If your server runs as nobody, you'll need to make your script world-executable (755).

Bad interpreter line
A Perl script should begin with a line that identifies the Perl interpreter on the local system, e.g.

#!/usr/local/bin/perl

If the line doesn't give the path of a valid Perl interpreter, an error will be generated. You can usually find out the path to the interpreter by using: 'which perl'

The interpreter line must be the first line of the script, and must begin with '#!'. The same principles apply when writing shell scripts using sh, csh etc.

Syntax error in script
Any syntax errors in your script will cause a 500 error. Perl allows you to check the script at the command line with:   perl -c MyScript.pl.

Another useful option is:   perl -w MyScript.pl - which issues compiler warnings that may highlight possible runtime problems with the script.

Missing required file
If a library requested with 'require' or 'use' can't be found, a 500 error will occur. Normally syntax-checking the script should detect this error, but in some cases the environment in which scripts are executed by the server may be different from the environment set up when the script is run at the command-line. Perl might find the library file correctly in one case, but not in another.

Runtime error in script
If the script runs into an execution error - for instance, a file not found, division by zero etc. - then a 500 error will occur. Runtime errors, particularly of the 'file not found' variety, can often be caused by differences between the Perl environment when executed under the server and the environment when executed from the command line. Trapping the error and printing the full path to the file that the script thinks it wants can often be very helpful.

Invalid HTTP header sent
The first output sent by a script must always be a valid HTTP header, typically:

Content-type: text/html

The headers must then be followed by two linefeeds before the actual content begins. Remember to check that print statements writing to other streams really do write to those other streams and not to standard output. Also beware of debugging comments written to standard error: some servers take their input from either STDOUT or STDERR, and because STDERR is line-buffered (text written to STDERR is sent out as soon as the line is complete) while STDOUT typically defaults to block-buffering (text is written when enough of it has been printed to fill a buffer), STDERR may 'get there first'. The following script would cause errors on some systems:

#!/usr/local/bin/perl
print "Content-type: text/plain\n\n";
print STDERR "OK so far\n";
print "Succeeded.";

because the server would see the 'OK so far' first, and fail to make sense of it. You can force line-buffering on STDOUT with: $|=1; placed early on in your script, which is probably a good thing to do anyway.

Wrong version of Perl
Make sure that you're not trying to run a Perl 5 script on a Perl 4 (or earlier!) interpreter. Note that Perl 4 scripts run on Perl 5 interpreters may give problems; in particular, strings that contain '@' may cause errors; '@' now needs to be escaped by inserting a backslash before it wherever it occurs in a string.

Error 404

404 errors are 'Object not found'. Just as you can get 'not found' errors with HTML documents, so you can get them with CGI scripts, and for the same reason.

The solution is to check your URL, and the path to your file, and ensure that the URL really does point to the place that you think it does. Remember also that some servers may not allow subdirectories in a designated cgi-bin directory, thus:

http://www.foo.com/cgi-bin/MyScript.pl - might be valid, while:

http://www.foo.com/cgi-bin/stuff/MyScript.pl - would fail.

"Document contains no data"
Sometimes, rather than getting an error message from the server, you may simply see a 'Document contains no data' message from your browser. This typically suggests that your script sent the content-header successfully - in other words, that it managed to execute at least in part - but failed to send any further information. Among the possible explanations are:

Script error
If your script fails after it has successfully sent a valid content header, you may not see any error reports from the server. Any of the usual runtime errors could cause this (such as files that couldn't be opened, 'die()' statements, division by zero etc.). Use the eval() technique to trap this kind of error.

Server timeout
If your script takes a very long time to run, the connection may time out before it sends any more data. If your script really does take a long time to run, your best solution is to make the results available as they come in; rather than buffering them up, try to trickle them down towards the user as they become available. Or consider using another strategy when running your script.

No output
For some reason, your script genuinely isn't sending any more data. It executes successfully, but success doesn't include writing anything to STDOUT. Check the logic of your script to be sure that all output statements are actually reached, and check how your streams are set up to be sure that you're really writing to STDOUT. Running the script at the shell prompt may help spot this kind of error.

Transient network or server failures
More rarely, errors can result from broken connections or from server failure (i.e. running out of memory, unable to fork any more processes). This is rare, but if your script runs intermittently, or runs one day and not the next, you might be suffering from this kind of problem.

Other Problems:

Script text displayed instead of executing

When you try to run the script, the script doesn't execute; instead, the browser simply displays the text of the script. The most likely reason for this is that you've installed the script in the wrong place, or given it the wrong name. Most servers are set up to execute only scripts placed in certain directories, or, more rarely, with certain suffixes (e.g. '.cgi'). If you put a script in the wrong directory, it won't be executed, and the text of the script will be returned as an ordinary text file.

Browser prompts you to save file when running a script

Instead of the output page you expect to see, you may receive a message from your browser asking you to save a file of type 'unknown' (or 'application/x-url-encoded' etc.). This is typically caused by a failure to send a proper Content-type: header.

'Here-document' problems

Among the hardest syntax errors to debug are those associated with 'here-documents' in Perl. These are expressions of the form:

print << "EndOfText";
Here's some text
EndOfText

The quoted 'EndOfText' token and the token that terminates the text to be printed must match exactly, or you'll see an error (when you check syntax) that reads: 'EndOfText' not found anywhere before end of file

Whitespace characters before or after the terminating token can cause the match to fail, so the 'EndOfText' token (or whatever string you're using) must be flush against the left margin, and there must be no trailing space after it. A particularly nasty 'gotcha' occurs when moving text files from DOS/Windows to UNIX.

Because DOS/Windows uses two characters - <CR> and <LF> - to delimit lines, where UNIX only uses one - <LF> - you could end up with invisible <CR> characters between your token and the following linefeed. You can't see these, but Perl can, and for Perl 'EndOfText<CR>' isn't the same as 'EndOfText'. The compilation will fail mysteriously.

Web Hosting by Netfirms | Free Domain Names by Netfirms

Online Services
META Tag
    Generator
Web Whois

Site Resources
Site Links
Earn Cash

DBMan FAQ

Creative Computing

Contact
Guest Book