You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Tim Noll <tn...@grapevine.net> on 2002/01/29 22:25:23 UTC
problems with DirectoryIndex under mod_perl + Template Toolkit
I'm using mod_perl + Template Toolkit, and I'm having trouble getting Apache
to pass the DirectoryIndex to my handler. The handler is supposed to take
the path_info and pull a template of the same name from a subdirectory
called 'html'.
This works fine for file names which do exist in the subdirectory. And, if
they don't exist, an error is correctly generated. However, if the path is
empty or '/', I expect Apache to include the DirectoryIndex (index.html) in
path_info or somewhere else that I can get to it. Unfortunately, Apache is
passing empty paths and '/' straight through to the handler, causing a file
not found error.
Maybe I'm just not looking in the right place, but I've spent a lot of time
Googling and looking at the mod_perl guide, and I can't seem to find an
exact answer to my problem. This would seem to be a common issue. Can anyone
offer a solution?
Admittedly, I'm new to Apache, mod_perl and Template Toolkit, and I'm
getting my feet wet trying to learn all three using my Windows 2000
workstation as a test bed, although the eventual target server will be
running Linux. Below is some sample code (mostly copied/modified from
various online sources) that I boiled down in an attempt to solve the
problem, but to no avail.
Thanks in advance.
-Tim
httpd.conf
----------
# default win32 config up to here ...
# mod_perl config
Include conf/perl.conf
----------------------------------------------------------------------
perl.conf
---------
LoadModule perl_module modules/mod_perl.so
AddModule mod_perl.c
PerlRequire conf/startup.pl
PerlWarn On
PerlTaintCheck On
PerlFreshRestart On
PerlSetVar websrc /usr/local/apache/tt
<Location /tt>
SetHandler perl-script
PerlHandler Test::Mod
</Location>
----------------------------------------------------------------------
startup.pl
----------
#!/usr/bin/perl -w
use strict;
BEGIN {
# modify include path
use Apache ();
use lib Apache->server_root_relative('lib/perl');
}
# are we under mod_perl?
$ENV{MOD_PERL}
or die("not running under mod_perl");
# detailed warnings
use Carp ();
$SIG{__WARN__} = \&Carp::cluck;
# load common modules
use Apache::Constants ();
use Template ();
# load custom modules
use Test::Mod ();
1;
----------------------------------------------------------------------
Test/Mod.pm
-----------
#!/usr/bin/perl -wT
package Test::Mod;
use strict;
use Apache::Constants qw( :common );
use Template qw( :template );
our $VERSION = 0.01;
sub handler {
my $r = shift;
my $websrc = $r->dir_config('websrc')
or return fail( $r, SERVER_ERROR, "'websrc' not specified" );
my $template = Template->new({
INCLUDE_PATH => "$websrc:$websrc/html:$websrc/html/include",
OUTPUT => $r,
});
# use the path_info to determine which template file to process
my $file = $r->path_info();
$file =~ s[^/][];
my $vars = {
uri => $r->uri(),
file => $r->filename(),
path => $r->path_info(),
tt => $file,
};
$r->content_type('text/html');
$r->no_cache(1);
$r->send_http_header();
$template->process($file, $vars)
or return fail( $r, SERVER_ERROR, $template->error() );
return OK;
}
sub fail {
my ($r, $status, $message) = @_;
$r->log_reason( $message, $r->filename() );
return $status;
}
----------------------------------------------------------------------
index.html
----------
[% PROCESS header.html
title = 'template test'
%]
<p>uri: [% uri %]</p>
<p>file: [% file %]</p>
<p>path: [% path %]</p>
<p>template: [% tt %]</p>
[% PROCESS footer.html %]
Re: problems with DirectoryIndex under mod_perl + Template Toolkit
Posted by Stas Bekman <st...@stason.org>.
Tim Noll wrote:
> Unfortunately, I could not get Apache::ShowRequest to compile, despite
> tinkering with it quite a bit. But, per your suggestion, I wrote a Fixup
> handler to solve this problem.
Good.
> However, in my web searches, I came across post after post that seem to
> describe the same problem or something similar. In no case have I seen a
> straightforward solution. Is there some reason why this isn't easier to
> handle if indeed it's such a common problem?
I don't think this has anything to do with mod_perl,
since it's a pure Apache configuration issue.
So you should probably talk to httpd people.
mod_perl simply let's you solve the problem with a custom fixup handler.
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: problems with DirectoryIndex under mod_perl + Template Toolkit
Posted by Tim Noll <tn...@grapevine.net>.
Unfortunately, I could not get Apache::ShowRequest to compile, despite
tinkering with it quite a bit. But, per your suggestion, I wrote a Fixup
handler to solve this problem.
However, in my web searches, I came across post after post that seem to
describe the same problem or something similar. In no case have I seen a
straightforward solution. Is there some reason why this isn't easier to
handle if indeed it's such a common problem?
-Tim
----- Original Message -----
From: "Stas Bekman" <st...@stason.org>
To: "Tim Noll" <tn...@grapevine.net>
Cc: <mo...@apache.org>; <te...@template-toolkit.org>
Sent: Wednesday, January 30, 2002 6:07 AM
Subject: Re: problems with DirectoryIndex under mod_perl + Template
Toolkit
> Tim Noll wrote:
>
> Tim, this question is not-related to TT, but a pure configuration
issue.
> So in further postings about this issue please don't CC the tt list.
> (CC'ing only once now).
>
> > I'm using mod_perl + Template Toolkit, and I'm having trouble
getting Apache
> > to pass the DirectoryIndex to my handler. The handler is supposed to
take
> > the path_info and pull a template of the same name from a
subdirectory
> > called 'html'.
> >
> > This works fine for file names which do exist in the subdirectory.
And, if
> > they don't exist, an error is correctly generated. However, if the
path is
> > empty or '/', I expect Apache to include the DirectoryIndex
(index.html) in
> > path_info or somewhere else that I can get to it. Unfortunately,
Apache is
> > passing empty paths and '/' straight through to the handler, causing
a file
> > not found error.
> >
> > Maybe I'm just not looking in the right place, but I've spent a lot
of time
> > Googling and looking at the mod_perl guide, and I can't seem to find
an
> > exact answer to my problem. This would seem to be a common issue.
Can anyone
> > offer a solution?
>
>
> That's the job of mod_dir to do that translation from / to
/index.html.
> Does it run? For example you can use Apache::ShowRequest to look what
> handlers are running.
>
> In your case the best thing is to write a Fixup handler and do what
> mod_dir does in Perl (should be two lines of code).
>
> Here is a section from our book with an example of using
> Apache::ShowRequest:
>
> =head2 Investigating the Request Phases
>
> Imagine a situation where you have a complex server setup in which
> many different Perl and non-Perl handlers participate in the request
> processing, and one or more of these handlers misbehave. A simple
> example would be where one of the handlers alters the request record,
> which breaks the functionality of the other handler. Or some handler
> invoked first in for any given phase of the process and returns C<OK>
> status, when it's not expected to do so, thus preventing other
> handlers from doing their job. You can't just add debug statements to
> trace the offender--there are too many handlers involved.
>
> The simplest solution is to get a trace of all registered handlers for
> each phase, stating whether they were invoked or not and what was the
> return status. Once such a trace is available, it's much easier to
> look only at the players who did something, thus narrowing the search
> path for a potential misbehaving module.
>
> The C<Apache::ShowRequest> module shows the phases the request goes
> through, displaying the module participation in each phase and respond
> codes. The content response phase is not run, but possible modules
> are listed as defined. To configure it, just add this snippet to
> I<httpd.conf>:
>
> <Location /showrequest>
> SetHandler perl-script
> PerlHandler +Apache::ShowRequest
> </Location>
>
> Now if you want to see what happens when you access some URI, just add
> it after I</showrequest>. C<Apache::ShowRequest> uses the
> C<PATH_INFO> to get to the URI that should be executed. So to run
> I</index.html> with C<Apache::ShowRequest>, issue a request to
> I</showrequest/index.html>. For I</perl/test.pl>, issue a request to
> I</showrequest/perl/test.pl>.
>
> This module produces rather lengthy output, so we will show only one
> section from the report generated while requesting:
> I</showrequest/index.html>:
>
> Running request for /index.html
> Request phase: post_read_request
> [snip]
> Request phase: translate_handler
> mod_perl ....................DECLINED
> mod_setenvif ................undef
> mod_auth ....................undef
> mod_access ..................undef
> mod_alias ...................DECLINED
> mod_userdir .................DECLINED
> mod_actions .................undef
> mod_imap ....................undef
> mod_asis ....................undef
> mod_cgi .....................undef
> mod_dir .....................undef
> mod_autoindex ...............undef
> mod_include .................undef
> mod_info ....................undef
> mod_status ..................undef
> mod_negotiation .............undef
> mod_mime ....................undef
> mod_log_config ..............undef
> mod_env .....................undef
> http_core ...................OK
> Request phase: header_parser
> [snip]
> Request phase: access_checker
> [snip]
> Request phase: check_user_id
> [snip]
> Request phase: auth_checker
> [snip]
> Request phase: type_checker
> [snip]
> Request phase: fixer_upper
> [snip]
> Request phase: response handler (type: text/html)
> mod_actions .................defined
> mod_include .................defined
> http_core ...................defined
> Request phase: logger
> [snip]
>
> For each stage, we get a report of what modules could participate in
> the processing and whether they have taken any action. As you can see,
> the content response phase is not run, but possible modules are listed
> as defined. If we run a mod_perl script, the response phase looks
> like:
>
> Request phase: response handler (type: perl-script)
> mod_perl ....................defined
>
>
>
>
> _____________________________________________________________________
> Stas Bekman JAm_pH -- Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide http://perl.apache.org/guide
> mailto:stas@stason.org http://ticketmaster.com http://apacheweek.com
> http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
>
>
>
Re: problems with DirectoryIndex under mod_perl + Template Toolkit
Posted by Stas Bekman <st...@stason.org>.
Tim Noll wrote:
Tim, this question is not-related to TT, but a pure configuration issue.
So in further postings about this issue please don't CC the tt list.
(CC'ing only once now).
> I'm using mod_perl + Template Toolkit, and I'm having trouble getting Apache
> to pass the DirectoryIndex to my handler. The handler is supposed to take
> the path_info and pull a template of the same name from a subdirectory
> called 'html'.
>
> This works fine for file names which do exist in the subdirectory. And, if
> they don't exist, an error is correctly generated. However, if the path is
> empty or '/', I expect Apache to include the DirectoryIndex (index.html) in
> path_info or somewhere else that I can get to it. Unfortunately, Apache is
> passing empty paths and '/' straight through to the handler, causing a file
> not found error.
>
> Maybe I'm just not looking in the right place, but I've spent a lot of time
> Googling and looking at the mod_perl guide, and I can't seem to find an
> exact answer to my problem. This would seem to be a common issue. Can anyone
> offer a solution?
That's the job of mod_dir to do that translation from / to /index.html.
Does it run? For example you can use Apache::ShowRequest to look what
handlers are running.
In your case the best thing is to write a Fixup handler and do what
mod_dir does in Perl (should be two lines of code).
Here is a section from our book with an example of using
Apache::ShowRequest:
=head2 Investigating the Request Phases
Imagine a situation where you have a complex server setup in which
many different Perl and non-Perl handlers participate in the request
processing, and one or more of these handlers misbehave. A simple
example would be where one of the handlers alters the request record,
which breaks the functionality of the other handler. Or some handler
invoked first in for any given phase of the process and returns C<OK>
status, when it's not expected to do so, thus preventing other
handlers from doing their job. You can't just add debug statements to
trace the offender--there are too many handlers involved.
The simplest solution is to get a trace of all registered handlers for
each phase, stating whether they were invoked or not and what was the
return status. Once such a trace is available, it's much easier to
look only at the players who did something, thus narrowing the search
path for a potential misbehaving module.
The C<Apache::ShowRequest> module shows the phases the request goes
through, displaying the module participation in each phase and respond
codes. The content response phase is not run, but possible modules
are listed as defined. To configure it, just add this snippet to
I<httpd.conf>:
<Location /showrequest>
SetHandler perl-script
PerlHandler +Apache::ShowRequest
</Location>
Now if you want to see what happens when you access some URI, just add
it after I</showrequest>. C<Apache::ShowRequest> uses the
C<PATH_INFO> to get to the URI that should be executed. So to run
I</index.html> with C<Apache::ShowRequest>, issue a request to
I</showrequest/index.html>. For I</perl/test.pl>, issue a request to
I</showrequest/perl/test.pl>.
This module produces rather lengthy output, so we will show only one
section from the report generated while requesting:
I</showrequest/index.html>:
Running request for /index.html
Request phase: post_read_request
[snip]
Request phase: translate_handler
mod_perl ....................DECLINED
mod_setenvif ................undef
mod_auth ....................undef
mod_access ..................undef
mod_alias ...................DECLINED
mod_userdir .................DECLINED
mod_actions .................undef
mod_imap ....................undef
mod_asis ....................undef
mod_cgi .....................undef
mod_dir .....................undef
mod_autoindex ...............undef
mod_include .................undef
mod_info ....................undef
mod_status ..................undef
mod_negotiation .............undef
mod_mime ....................undef
mod_log_config ..............undef
mod_env .....................undef
http_core ...................OK
Request phase: header_parser
[snip]
Request phase: access_checker
[snip]
Request phase: check_user_id
[snip]
Request phase: auth_checker
[snip]
Request phase: type_checker
[snip]
Request phase: fixer_upper
[snip]
Request phase: response handler (type: text/html)
mod_actions .................defined
mod_include .................defined
http_core ...................defined
Request phase: logger
[snip]
For each stage, we get a report of what modules could participate in
the processing and whether they have taken any action. As you can see,
the content response phase is not run, but possible modules are listed
as defined. If we run a mod_perl script, the response phase looks
like:
Request phase: response handler (type: perl-script)
mod_perl ....................defined
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/