- publishing free software manuals
The Apache HTTP Server Reference Manual
by Apache Software Foundation
Paperback (6"x9"), 862 pages
ISBN 9781906966034
RRP £19.95 ($29.95)

Get a printed copy>>>

9.4  But it’s still not working!

There are four basic things that you may see in your browser when you try to access your CGI program from the web:

The output of your CGI program
Great! That means everything worked fine. If the output is correct, but the browser is not processing it correctly, make sure you have the correct Content-Type set in your CGI program.
The source code of your CGI program or a "POST Method Not Allowed" message
That means that you have not properly configured Apache to process your CGI program. Reread the section on configuring Apache and try to find what you missed.
A message starting with "Forbidden"
That means that there is a permissions problem. Check the Apache error log and the section below on file permissions.
A message saying "Internal Server Error"
If you check the Apache error log, you will probably find that it says "Premature end of script headers", possibly along with an error message generated by your CGI program. In this case, you will want to check each of the below sections to see what might be preventing your CGI program from emitting the proper HTTP headers.

9.4.1  File permissions

Remember that the server does not run as you. That is, when the server starts up, it is running with the permissions of an unprivileged user - usually nobody, or www - and so it will need extra permissions to execute files that are owned by you. Usually, the way to give a file sufficient permissions to be executed by nobody is to give everyone execute permission on the file:

chmod a+x first.pl

Also, if your program reads from, or writes to, any other files, those files will need to have the correct permissions to permit this.

9.4.2  Path information and environment

When you run a program from your command line, you have certain information that is passed to the shell without you thinking about it. For example, you have a PATH, which tells the shell where it can look for files that you reference.

When a program runs through the web server as a CGI program, it may not have the same PATH. Any programs that you invoke in your CGI program (like sendmail, for example) will need to be specified by a full path, so that the shell can find them when it attempts to execute your CGI program.

A common manifestation of this is the path to the script interpreter (often perl) indicated in the first line of your CGI program, which will look something like:

#!/usr/bin/perl

Make sure that this is in fact the path to the interpreter.

In addition, if your CGI program depends on other environment variables, you will need to assure that those variables are passed by Apache.

9.4.3  Program errors

Most of the time when a CGI program fails, it’s because of a problem with the program itself. This is particularly true once you get the hang of this CGI stuff, and no longer make the above two mistakes. The first thing to do is to make sure that your program runs from the command line before testing it via the web server. For example, try:

cd /usr/local/apache2/cgi-bin
./first.pl

(Do not call the perl interpreter. The shell and Apache should find the interpreter using the path information on the first line of the script.)

The first thing you see written by your program should be a set of HTTP headers, including the Content-Type, followed by a blank line. If you see anything else, Apache will return the Premature end of script headers error if you try to run it through the server. See Writing a CGI program above for more details.

9.4.4  Error logs

The error logs are your friend. Anything that goes wrong generates message in the error log. You should always look there first. If the place where you are hosting your web site does not permit you access to the error log, you should probably host your site somewhere else. Learn to read the error logs, and you’ll find that almost all of your problems are quickly identified, and quickly solved.

9.4.5  Suexec

The suexec (p. 1509) support program allows CGI programs to be run under different user permissions, depending on which virtual host or user home directory they are located in. Suexec has very strict permission checking, and any failure in that checking will result in your CGI programs failing with Premature end of script headers.

To check if you are using suexec, run apachectl -V and check for the location of SUEXEC_BIN. If Apache finds an suexec binary there on startup, suexec will be activated.

Unless you fully understand suexec, you should not be using it. To disable suexec, simply remove (or rename) the suexec binary pointed to by SUEXEC_BIN and then restart the server. If, after reading about suexec (p. 1509), you still wish to use it, then run suexec -V to find the location of the suexec log file, and use that log file to find what policy you are violating.

ISBN 9781906966034The Apache HTTP Server Reference ManualSee the print edition