We are using
RedHat Linux apache 1.3.14 mod_perl_1.23_01
Our site is set up to generate pages using a templating system to add
custom headers footers and sidebars. As well we use .htaccess files to
further customize the subprocess_env.
We are using custom modules installed as PerlFixupHandlers both for
template generation and multilingual negotiation
Negotiation.pm handles lingual content negotiation. It determines
what version of the page to present based on the users preferred
variants and the available variants for that page.When the best match
is found, it
performs an internal redirect to that document.
Template.pm is installed as a fixup handler, and is controlled through
various PerlSetVar directives.
Basically, it determines what to include at the beginning and end of
the web page.
fixup sets the content handler for the request.
Also has two subroutines, handle_rec for static pages ,and handle_cgi
for scripts These allow the auto-inclusion of headers and footers of web
pages.
In httpd.conf
--------------
DirectoryIndex index.cgi index.html
PerlRequire /www/perl/libs/WRI/Template.pm
PerlRequire /www/perl/libs/WRI/Negotiation.pm
PerlFixupHandler WRI::Negotiation WRI::Template::fixup
---------------------------------------------------
These modules work 90% of the time....
The problem occurs when a directory is requested, and served as a
negotiated document
and is passed to our content handler. (handle_cgi)
A save-as window pops up in the browser and Apache logs a 500
error. (The file it is trying to save is the standard 500 internal
error message.)
In the Template::fixup handler, the
document is being detected as a cgi-script, not a server-parsed
document. The 500 occurs because we are trying to execute a static
document or directory.
Template.pm
In run_cgi:
unless (open(CGI,'-|')) {
#don't need the writing handle to the pipe anymore
close(WR);
#make STDIN be the read handle of the pipe (so we can get
#POST information from Apache)
open(STDIN,'<&RD');
#Run in the directory of the file
$r->chdir_file($filename);
### This returns 500 when a directory or static file is negotiated ###
#Run the file
exec($filename) || return SERVER_ERROR;
}
Error Log:
[Wed Jan 31 13:04:52 2001] [error] Can't use string ("500") as a symbol
ref while "strict refs" in use at /www/perl/libs/WRI/Template.pm line
302.
[Wed Jan 31 13:04:55 2001] [error] Usage: Apache::cgi_header_out(r,
key,
...) at /www/perl/libs/WRI/Template.pm line 433.
These lines numbers may not be accurate since we have added and
deleted
debugging code..
Template.pm - handle_cgi:
#FIXME - needs error checking. If run CGI fails, $cgi will have
# the number 500 instead of a file handle, and will fail
later on
my $cgi = run_cgi($r, $r->filename(), $r->uri());
line 302:
while (<$cgi>) {
#remove the trailing body and html tags from the CGI output
#if we are using includes
if ($addincs) {
s!</(body|html)[^>]*>!!gio;
}
#print out the line that we just read
$r->print($_);
}
.
.
.
do {
#Quit if this is the end of the headers
last if ($_ eq $/);
#remove the LF or CRLF
chomp;
#Give apache the header line
unless ($is_sub) {
line 433: $r->cgi_header_out(split(/:\s*/,$_,2));
}
} while (<CGI>);
---------------------------------------------
My understanding is that when OK or DECLINED is returned from these
modules in the list of fixup handlers, control passes to the next,
and when DONE is returned, the remaining are
skipped mod_dir regains control and the next default file is requested
(index.cgi index.html)
Is this correct or is there something I am misunderstanding.
Request Outline
---------------
mod_dir sends directory request to Negotiation.pm
/products/student/calcwiz/
returns OK from Nego.pm
mod_dir then sends index.cgi - index.html
Nego.pm negotiates index.cgi and each of available variations
then index.html ......
when found most appropriate
Negotiating:
/products/student/calcwiz/index.en.html
Template.pm
handling request..
/products/student/calcwiz/index.en.html
Another Clue
This error recurs when the page is reloaded 25 - 30 times
MaxRequestsPerChild is 30
Could this be related to our problem.
I appreciate any clues anyone may have to why this problem occurs.
Thanks in advance,
Judy
