title: Things obvious to others, but not to you


=head1 Coverage

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








=head1 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 C<ErrorLog> directive. My httpd.conf says:

  ErrorLog var/logs/error_log

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

  ServerRoot /usr/local/apache/

So my error_log file is C</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
C<ErrorLog> directive, the error message will be printed to STDERR.
If the error happens when the server executes a C<PerlRequire> or
C<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 (C<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 C<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 C<LogHandler>, the C<ErrorLog> directive may have no
effect. But you can also do something at this handler and then return
C<DECLINED> status, so the default Apache LogHandler will do the work
as usual.

</META>

=head1 Setting Environment Variables For Scripts Called From CGI.

Perl uses C<sh()> for its C<system()> and C<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.

=cut









