Solving a 500
Internal Server Error
By Christopher S L Heng |
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:
<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:
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.
Source:
Copyright by Christopher S L Heng. All rights reserved.
Get more free tips and articles like this, on web design, promotion,
revenue and scripting, from http://www.thesitewizard.com/.
More Articles
|
.
|
|
[an error occurred while processing this directive]
|
|
|
|
|
