|
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.
- 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.
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.
The exception to this is when the server is configured to use
suexec. This 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 an "Internal Server
Error". In this case, you will need to check the suexec log file to see what specific
security check is failing.
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 does not have that 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.
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. Always attempt to run your program from the command line before you
test if via a browser. This will eliminate most of your problems.
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.
|
