From the number of questions I get from my visitors at thesitewizard.com, 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):
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.
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. 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.
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 a Windows FTP program, find some way to change the permissions of the file to allow "Read", "Write" and "Execute" permissions for the owner, and "Read" and "Execute" permissions for the group and everyone else.
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 "@".
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.
One way to do this is to install a copy of the Perl interpreter on your computer. You can get a version of Perl for your operating system from the Free Perl Compilers, Interpreters, Ports, Binaries, Source Code and Implementations page.
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:
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:
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.
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 your own 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:
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:
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.
Copyright 2000-2013 by Christopher Heng. All rights reserved.
Get more free tips and articles like this,
on web design, promotion, revenue and scripting, from https://www.thesitewizard.com/
Do you find this article useful? You can learn of new articles and scripts that are published on thesitewizard.com by subscribing to the RSS feed. Simply point your RSS feed reader or a browser that supports RSS feeds at https://www.thesitewizard.com/thesitewizard.xml. You can read more about how to subscribe to RSS site feeds from my RSS FAQ.
This article is copyrighted. Please do not reproduce or distribute this article in whole or part, in any form.
It will appear on your page as:
Perl CGI Debugging: How to Solve a 500 Internal Server Error
