CGI Programming OpenFAQ

My CGI scripts don't work. What's wrong?

Contributors:

The Server Must Recognize Your Program

Simply linking from your page to an executable program or script won't cause it to be run by the server. There are two common arrangements: either files in directories specially designated by the server administrator are executed as CGI scripts, or files with a special extension (such as .cgi) are executed as CGI scripts.

These are just two possible ways your server might be configured. Many sites don't allow users to run CGI scripts at all. Consult your web server's administrator.

Always Output a MIME Type

Every CGI script must output a MIME type indicating what kind of document it is producing. If your script outputs an HTML page, the correct format is:

Content-type: text/html

Followed by two line feeds (ascii 10 decimal).

After the MIME type, output the desired HTML.

Always Flush Output

On many systems, unexpected problems can result when a CGI script outputs a MIME type, then executes another program to generate output. To prevent such problems, flush standard output before executing other programs. If your script is written in C, the proper code is usually: fflush(stdout);

Permissions and Paths: Why Can't My Script Access My Files?

CGI programs typically execute with a current directory and user ID that differ from your personal home directory and user ID. When you write CGI programs, make sure any files accessed are accessed by absolute path (beginning from the root of the file system). Also, users of multiuser systems such as Unix may have to grant all users read access or even write access to data files using the chmod command. This is not an ideal situation. Better servers run your CGI programs using your user ID. Talk to your admin if you have difficulties in this area.

When One Browser Works and Another Doesn't

Some browsers are tolerant of incorrect Content-type headers, as well as of null characters in text/html or text/plain output. Make sure your output is strictly correct; it helps to check the script with several different browsers.

Obtaining Complete Error Messages From CGI Programs

Programmers in all languages can often obtain any messages that were written to "standard error" by examining the error log of the web server. The error log is typically in the same directory with the main web server log file.

Perl programmers wanting to know what the actual error was in detail when a CGI program fails can add the following code to their programs.

I have just learned a nice snippet to use for CGI debugging, put at the beginning of your code or even better in BEGIN{} block then any time your script calls die() or warn() All the STDERR will be printed to your browser's window. So from now on no need to use error logs , almost :-)

  
          ## death handler, presumes no output yet
          $SIG{``__DIE__''} = $SIG{``__WARN__''} = sub {
            my $error = shift;
            chomp $error;
            $error =~ s/[<&>]/``&#''.ord($&).``;''/ge;  # entity escape;
            print ``Content-type: text/html\n\n[$error]\n'';
            exit 0;
          };

Example:
open FILE, $file or die "Can't open $file:$!\n";

If the open call fails, you will see the message you passed to die() in your browsers's window.

This code was written by Randal L. Schwartz.

The CGI module, perl, and seeing errors

If your code fails in some way, you often end up with error messages that get output at the wrong point (e.g. before the Content-Type). These are then not valid headers for the data to be returned to the browser.

In order to see error messages within the browser, you can say

  use CGI;
  use CGI::Carp qw(fatalsToBrowser);

Then any die calls within a perl program get routed back to the browser rather than disappearing into an error logfile to which you may not have access.

Previous | Next | Table of Contents