Recipe 8.5 Testing That CGI Is Set Up Correctly

Problem

You want to test that you have CGI enabled correctly. Alternatively, you are receiving an error message when you try to run your CGI script and you want to ensure the problem doesn't lie in the web server before you try to find a problem in the script.

Solution

#! /usr/bin/perl
print "Content-type: text/plain\r\n\r\n";
print "It's working.\n";

And then, if things are still not working, look in the error log.

Discussion

Because Perl is likely to be installed on any Unixish system, this CGI program should be a pretty safe way to test that CGI is configured correctly. In the event that you do not have Perl installed, an equivalent shell program may be substituted:

#! /bin/sh
echo Content-type: text/plain
echo
echo It\'s working.

And, if you are running Apache on Windows, so that neither of the above options works for you, you could also try this with a batch file:

echo off
echo Content-type: text/plain
echo.
echo It's working.

Make sure that you copy the program code exactly, with all the right punctuation, slashes, etc., so that you don't introduce additional complexity by having to troubleshoot the program itself.

In either case, once the program is working, you should see something like the following screen capture (see Figure 8-1).

Figure 8-1. Your CGI program worked

The idea here is to start with the simplest possible CGI program to ensure that problems are not caused by other complexities in your code. We want to ensure that CGI is configured properly, not to verify the correctness of a particular CGI program.

There are a variety of reasons why a particular CGI program might not work. In very general terms, it can be in one of three categories: misconfiguration of the web server, an error in the program itself, or incorrect permissions on the files and directories in question.

Fortunately, when something goes wrong with one of your CGI programs, an entry is made in your error log. Knowing where your error log is located is a prerequisite to solving any problem you have with your Apache server. The error messages that go to the browser, while vaguely useful, tend to be catch-all messages and usually don't contain any information specific to your actual problem.

Ideally, if you have followed the recipes earlier in this chapter, you will not be having configuration problems with your CGI program, which leaves the other two categories of problems.

If your problem is one of permissions, you will see an entry in your logfile that looks something like the following:

[Sun Dec  1 20:31:16 2002] [error] (13)Permission denied: exec of /usr/local/apache/
     cgi-bin/example1.cgi failed

The solution to this problem is to make sure that the script itself is executable:

# chmod a+x /usr/local/apache/cgi-bin/example1.cgi

If the problem is an error in the program itself, then there are an infinite number of possible solutions, as there are an infinite number of ways to make any given program fail. If the example program given above works correctly, you can be fairly assured that the problem is with your program, rather than with some other environmental condition.

The error message Premature end of script headers, which you will see frequently in your career, means very little by itself. You should always look for other error messages that augment this message. Any error in a CGI program will tend to cause the program to emit warnings and error message prior to the correctly formed HTTP headers, which will result in the server perceiving malformed headers, resulting in this message. The suexec wrapper can also confuse matters if it's being used.

One particularly common error message, which can be rather hard to track down if you don't know what you're looking for, is the following:

[Sat Jul 19 21:39:47 2003] [error] (2)No such file or directory: exec of /usr/local/
     apache/cgi-bin/example.cgi failed

This error message almost always means one of two things: an incorrect path or a corrupted file.

In many cases, particularly if you have acquired the script from someone else, the #! line of the script may point to the wrong location (such as #!/usr/local/bin/perl, when perl is instead located at /usr/bin/perl). This can be confirmed by using the which command and comparing it to the #! line. For example, to find the correct location for Perl, you would type:

% which perl

The other scenario is that the file has been corrupted somehow so that the #! line is illegible. The most common cause of this second condition is when a script file is transferred from a Windows machine to a Unixish machine, via FTP, in binary mode rather than ASCII mode. This results in a file with the wrong type of end of line characters, so that Apache is unable to read correctly the location of the script interpreter.

To fix this, you should run the following one-liner from the command line:

% perl -pi.bak -le 's/\r//;' example.cgi

This will remove all of the Windows-style end-of-line characters, and your file will be executable.

See Also

• "Debugging `premature end of script headers'"

• Appendix B