Coverage

This document describes "special" traps you may encounter when running your plain CGIs under Apache::Registry and Apache::PerlRun.

Where do the warnings/errors go?

Your CGI does not work and you want to see what the problem is. The best idea is to check out any errors that the server may be reporting. Where you can find these errors?

Generally all errors are logged into an error_log file. The exact file location and name are defined in the http.conf file. Look for the ErrorLog directive. My httpd.conf says:

ErrorLog var/logs/error_log

But note that this path is relative to the ServerRoot. Apache prepends the value of ServerRoot to this value. In my configuration file I have:

ServerRoot /usr/local/apache/

So my error_log file is /usr/local/apache/var/logs/error_log.

There are cases when errors don't go to the error_log file. For example, some errors go to the httpd process' STDERR. If you haven't redirected httpd's STDERR then the messages are printed to the console (tty, terminal) from which you executed the httpd. This happens when the server didn't get as far as opening the error_log file for writing before it needed to write an error message.

For example, if you have entered a non-existent directory path in your ErrorLog directive, the error message will be printed to STDERR. If the error happens when the server executes a PerlRequire or PerlModule directive you might also see output sent to STDERR.

You are probably wondering where all the errors go when you are running the server in single process mode (httpd -X). They go to STDERR. This is because the error logging for all the httpd children is normally done by the parent httpd. When httpd runs in single process mode, it has no parent httpd process to perform all the logging. The output to the terminal includes all the status messages that normally go to the error_log file.

Finally with a PerlLogHandler you can take away from Apache its control of the error logging process for all HTTP transactions. If you do this, then you are responsible for generating and storing the error messages. You can do whatever you like with the information, (including throwing it away -- don't do it!) and, depending on how you implement you LogHandler, the ErrorLog directive may have no effect. But you can also do something at this handler and then return DECLINED status, so the default Apache LogHandler will do the work as usual.

</META>

Setting Environment Variables For Scripts Called From CGI.

Perl uses sh() for its system() and open() calls. So if you want to set a temporary variable when you call a script from your CGI you do something like this:

open UTIL, "USER=stas ; script.pl | " or die "...: $!\n";

or

system "USER=stas ; script.pl";

This is useful, for example, if you need to invoke a script that uses CGI.pm from within a mod_perl script. We are tricking the Perl script into thinking it's a simple CGI, which is not running under mod_perl.

open(PUBLISH, "GATEWAY_INTERFACE=CGI/1.1 ; script.cgi
     \"param1=value1&param2=value2\" |") or die "...: $!\n";

Make sure that the parameters you pass are shell safe -- all "unsafe" characters like single-quote and back-tick should be properly escaped.

Unfortunately mod_perl uses fork() to run the script, so you have probably thrown out the window most of the performance gained from using mod_perl. To avoid the fork, change script.cgi to a module containing a subroutine which you can then call directly from your mod_perl script.