Error 500 or Internal Server Error

This error can be caused by one of few problems. Such as the following:

File Execute permissions not set correctly

The file permission bits must be set to allow it to be executed. You'll need to make your script world-executable with:

chmod a+x yourscript.pl
at the Telnet command line.

If the server runs scripts using your own UID, you can use:

chmod u+x yourscript.pl
at the Telnet command line.

You can also set the file permission attributes using your FTP client program. Most scripts need to be set to 755 (RWX-RX-RX) and the data directories and data files usually to 777 (RWX-RWX-RWX)

See also: Unix file permissions

Bad interpreter line

A Perl script should begin with a line that identifies the Perl interpreter on the local system, f.e. #!/usr/local/bin/perl or #!/usr/bin/perl

If this line doesn't give the correct path to a Perl interpreter, the error will be generated. You can usually find out the path to the interpreter by using:
which perl
at the Telnet command line.

The interpreter line must always be the first line of the script, and must begin with #!.

Syntax error

Any syntax errors in your script will cause a 500 error. Perl allows you to check the script at the Telnet command line with:

perl -c yourcript.pl or perl -w yourcript.pl

which issues compiler warnings that may highlight possible runtime problems. Also look in your system's error log.

Missing required file

If a library requested with require or use can't be found a 500 error will occur. Syntax checking 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 in one instance, but not in another instance.

Runtime error

If the script runs into an execution error such as file not found or division by zero, a 500 error will occur. Runtime errors, particularly of the file not found type, are caused by differences between the Perl environment when executed under the server and the environment when executed from the command line. They're very difficult to detect and fix. Check all things again, paths in scripts, file permissions, binary or ascii upload, .htaccess file needed for parsing .html and .htm pages, etc..?

Invalid HTTP header sent

The first output sent by a script must always be a valid HTTP header, f.e.:

Content-type: text/html or Content-type: text/plain\n\n

The header must always be followed by two linefeeds.

Wrong version of Perl

Make sure you have the correct version of Perl. To find out which version you have try:

perl -e `print $]`

at the Telnet command line. At the UNIX prompt see which version of Perl you're running. If it turns out to be Perl 4, there may be a Perl 5 interpreter installed in the same directory, but with the name perl5. Perl 4 scripts run on Perl 5 interpreters may give problems; strings that contain '@' may cause errors; '@' needs to be escaped by inserting a \ before it wherever it occurs in a string, f.e.

me\@mydomain.net;

Server configuration errors

The server may be configured wrongly. If you get a 500 error, then you know that it's caused by one of the other error causes mentioned above. If a runtime error occurs inside the main subroutine, you get useful debugging output to help you identify it. During execution of scripts, errors are logged to your server's error log. The error log will contain the actual error message issued by the Perl interpreter. You may or may not have access to the error log. The location of the log varies from system to system, depending on how the server is set up.

Error 404

Object not found errors. Check your URL settings and the absolute and http paths to your file(s). The relationship between a pathname on the server and the correct URL can be unclear. Some servers (webmasters, that is) do not allow subdirectories in a cgi-bin directory or do not allow html or other files to be executed from a cgi-bin directory or its subdirectory. Check all path settings in the script.

Document contains no data

You may get a Document contains no data message from your browser. This suggests that your script sent the content-header successfully but failed to send any further information. This can be caused by a:

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.

Server timeout: if your script takes a very long time to run, the connection may time out before it sends any more data. Adjust the server's timeout period if you can.

No output: the script isn't sending any data. Check the logic of your script to be sure that all output statements are reached, and check how your streams are set up to be sure that you're really writing to STDOUT. Running the script at the Telnet shell prompt may help.

Transient network or server failures: errors can result from broken connections or from server failure.

Script text displayed instead of being executed

If the script doesn't execute, but the browser displays the text of the script, it is probably installed in the wrong place. Most servers are set up to execute only scripts placed in certain directories, or with certain suffixes (.cgi, .pl). If you put a script in the wrong directory, it will not be executed, and the text of the script will be returned as a text file.

Browser prompts you to save file

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

Finding the error using Telnet

If you're having trouble with a Perl CGI script, you can often find the exact error message by running it from the UNIX prompt in Telnet. Run it from the prompt with the word perl before it:

cd cgi-bin (or wherever the script is located)
perl yourperlscript.pl

The CGI script will then run as if it were called from a Web browser, but you'll see the exact output from the script appear in the Telnet window.