How to Resolve a 500 Internal Server Error in CGI Script

WebmasterCentral

Articles & Guides

Essence of India

From the number of questions I get from my visitors, I can see that one of the most dreaded errors that newcomers to CGI face is the "500 Internal Server Error". It is one of the most uninformative error messages that can mean anything from an improper upload to a bug in the script. This article attempts to give you some concrete, practical steps that you can take to narrow down the problem and hopefully eliminate it.

For the uninitiated, a "500 Internal Server Error" is a message much like the common "404 File Not Found" message. You get the latter message in your browser when you try to access a non-existent web page. You get the "500 Internal Server Error" message when you try to run a script with problems.

For the purposes of this article, I am assuming that your CGI script is a Perl script, by far the most commonly available on the Internet.

We will try to eliminate the most common errors first (and the easiest-to-eliminate ones):

1. Location

Did you upload your scripts into the right place? This is not as obvious as it may seem. Some servers are configured to run your CGI scripts anywhere. Others will only run it when it is installed in a particular directory. It is not just a matter of creating a "cgi-bin" directory - for example, some hosts configure the server so that it will run scripts only from a particular directory outside the web directory structure (for security reasons). Your web page will still call the script "/cgi-bin/script.pl" but the server maps it to the actual directory. You will have to upload it in the right directory, regardless of what your web page calls it. Find out such information from your web host's documentation.

2. File Upload Mode

Did you upload your Perl script in ASCII mode? Your FTP client may have uploaded the script in binary mode if you did not take any special action. Perl scripts are ASCII files, and since different operating systems have different ways of representing the end of line character (eg Unix uses a line-feed, Windows uses a carriage-return and line-feed pair), it is important that you set the uploading method to ASCII, so that line-end translation is performed.

Re-upload the script, this time making sure that it was uploaded in Text or ASCII mode. If you are using a Windows FTP program like WS_FTP, make sure that the radio button "ASCII" is selected and not "Binary" or "Auto". Do not use any auto-detection options since the FTP program might assume the extensions you are using for your scripts are for binary files.

3. File Permissions

Did you change the permissions on your script so that it can be executed on your web server? In most cases, simply uploading the Perl script to the server does not necessarily mean that it can run. On Unix web servers (like Linux, BSD, Solaris, etc), it is necessary to change the file permissions to indicate to the operating system that the file may be executed. If you have a Unix FTP client, set the permission ("chmod") of the file to 755, which allows the script to be executed by everybody. If you are using WS_FTP from Windows, right click the file that you've just uploaded and choose "chmod". You will be presented with a dialog box where you should check "Read, Write, Execute" for the owner, "Read, Execute" for the group and everyone else.

4. Check Modifications

If you actually had to modify the script to configure it, did you introduce new errors into the script? If you are not the author, get another copy of the original script (prior to your changes) and compare it with your current script. Perhaps you forgot to place a semi-colon (";") after a particular variable assignment. Or perhaps you added special reserved characters in your double-quoted strings - for example if your double-quoted string (strings enclosed in the " quote character) has a "$" or "@" embedded in it, make sure that it is preceded with a backslash, ie, use "\$" to get a "$", and "\@" to get a "@".

5. Tracking Errors in the Script

If you did extensive editing of the script (such as to change the HTML code that it prints, etc), then it is possible the error is in the changes you introduced. You will need to check that there are no syntax errors.

The simplest way to do this is to install a copy of the Perl interpreter on your computer. You can get Perl for your operating system from:
http://www.perl.com/

If you use Windows, just go directly to the following URL and download it (the above link will simply point you there anyway):
http://www.activestate.com/

Perl is free, so you needn't worry about how much it might cost you. And you need it if you're using Perl CGI scripts.

First, run your script with a command line like:

perl -wc scriptname.pl

This will cause the Perl interpreter to check your script for syntax errors without running it.

If that seems to work out, try running it without the syntax check options:

perl -w scriptname.pl

If there are any syntax errors, or errors during execution, you might be able to get a diagnostic message from the Perl interpreter. This will help you trace the problem since such messages usually come with a line number in the script which you can double-check.

6. Supplying Inputs to the Script

If you only get the error when a certain form input is given to the script, you will need to supply those inputs. You can actually supply those inputs without needing to set up a web server.

First look at your form.

For every INPUT, TEXTAREA and SELECT tag that has a "name" attribute, note down what the "name" attribute is and what sort of content should go into it. For values that are to be completed by the user, think up some hypothetical values for testing purposes. Take the following form as an example:

The form actually supplies two fields to the Perl script. Let's say the user enters "M. Name" in the Fullname field. Your script should receive the following information:

recipient=John@Doe.com
Fullname=M Name

The information will be formulated as a single lined string, like

recipient=John@Doe.com&Fullname=M+Name

Notice that the two strings are joined together with an ampersand ("&") as the glue. The space in the name is also converted to a plus sign ("+").

If the form has a "GET" method (check the FORM tag itself), the above information will be placed in the QUERY_STRING environment variable, like this:

QUERY_STRING=recipient=John@Doe.com&Fullname=M+Name

If the form has a "POST" method the line will be placed in the standard input (stdin) to the script.

To test the script offline using the GET method, simply set the QUERY_STRING environment variable accordingly. If you are using Windows, you might use the following command line in a DOS window prior to running the script in the same window:

set QUERY_STRING=recipient=John@Doe.com&Fullname=M+Name

To test the script offline using the POST method, put the line below into a text file named, say, testinput.txt.

recipient=John@Doe.com&Fullname=M+Name

Then redirect that file as an input to the script. On Unix systems as well as under Windows' MSDOS prompt, you can do it this way:

perl -w scriptname.pl < testinput.txt

Your script will then receive that input as though it was sent it by a form on the website. Check the error messages that perl spouts, if any, to help you track the problem in the script.

Summary

Basically, when you get a "500 Internal Server Error", check for the obvious and easy-to-solve errors like the file uploading problems and the executable-bit setting first. Once that is eliminated, it looks like there is a syntax error or some other problem in the script itself. The simplest way to track that is to let the Perl interpreter do the hard work: run the script on your own machine, where you can see the error messages from the Perl interpreter directly. With that strategy in your hand, a "500 Internal Server Error" will not seem to be such a formidable problem anymore.