to Resolve a 500 Internal Server Error in CGI Script
How to Resolve a 500 Internal Server Error in CGI Script
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
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
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:
If you use Windows, just go directly to the following URL and download
it (the above link will simply point you there anyway):
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
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:
<input type=hidden name="recipient" value="John@Doe.com">
Full Name: <input type=text name="Fullname">
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:
The information will be formulated as a single lined string, like
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:
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:
To test the script offline using the POST method, put the line below
into a text file named, say, testinput.txt.
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.
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.
About the Author
Christopher S L Heng.
Get more free tips and articles like this, on web design, promotion,
revenue and scripting, from http://www.thesitewizard.com/.
Cascading Style Sheets (CSS)
Guides & Articles
Guides & Articles..
Domain Name Registration