Common problems during CGI scripts installation

This document describes possible causes for errors in CGI scripts, particularly those that lead to a 'Server 500 Error' and a terse and unhelpful message advising you to contact the server administrator. The note mostly deals with Perl scripts and UNIX platforms, but some of the suggestions can apply to CGI programs written in other languages or running on other platforms as well. You can treat this note as a kind of checklist - when you get an error, read through it and check each possible cause in turn.

• Server error (Error 500)
• Not found (Error 404)
• Other common problems

Error 500

Messages reporting 'Error 500' or 'internal server error' can be caused by a number of possible problems. This section briefly lists and explains some of the commonest causes of such errors.

Execute permissions not set correctly (server can also report "403 Permission Denied" error).

For a script to run, the permissions bits must be set to allow it to be executed. If your server runs CGI script as user "nobody", you'll need to make your script world-executable with:

    chmod 755 myscript.cgi

If the server runs CGI scripts using your own UID (user ID), you can set 744 permissions

    chmod 744 myscript.cgi

Scripts are uploaded in binary mode.

When uploading CGI-scripts, use must use ASCII mode (not binary). This error occurs when uploading text files from Windows to UNIX. Because Windows uses two characters - <CR> and <LF> - to delimit lines, where UNIX only uses one - <LF> - you could end up with invisible <CR> characters between your token and the following linefeed. You can't see these, but Perl can, and for Perl 'Line<CR>' isn't the same as 'Line'. The compilation will fail mysteriously.

Bad interpreter line

A Perl script should begin with a line that identifies the Perl interpreter on the local system, e.g.

    #!/usr/bin/perl

If the line doesn't give the path of a valid Perl interpreter, an error will be generated. You can usually find out the path to the interpreter by using:

    which perl

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

 

Error 404

404 errors are 'Object not found'. Just as you can get 'not found' errors with HTML documents, so you can get them with CGI scripts, and for the same reason. The solution is to check your URL, and the path to your file, and ensure that the URL really does point to the place that you think it does. Please note, directory and filename portion of URL is case-sensitive on Unix filesystem.

The relationship between a pathname on the server and the correct URL for referencing it can sometimes be non-obvious, particularly if server scripts are run in a "chroot" environment (where, for security reasons, scripts run by the server are set up to see only a part of the filesystem), or the server configuration files specify a complex mapping from a URL path to an actual path in the filesystem. Remember also that some servers may not allow subdirectories in a designated cgi-bin directory, thus:

    http://www.foo.com/cgi-bin/myscript.cgi

might be valid, while:

    http://www.foo.com/cgi-bin/stuff/myscript.cgi

would fail.

Other problems

Some other possible problems include:

Script text displayed instead of executing

When you try to run the script, the script doesn't execute; instead, the browser simply displays the text of the script. The most likely reason for this is that you've installed the script in the wrong place, or given it the wrong name. Most servers are set up to execute only scripts placed in certain directories, or, more rarely, with certain suffixes (e.g. '.pl'). If you put a script in the wrong directory, it won't be executed, and the text of the script will be returned as an ordinary text file.

AtomicSoft offers optional installation service.