Re: problems with DirectoryIndex under mod_perl + Template Toolkit
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:[EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] To: Tim Noll [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] 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 COK 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 CApache::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 Ihttpd.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. CApache::ShowRequest uses the CPATH_INFO to get to the URI that should be executed. So to run I/index.html with CApache::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
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'
%]
puri: [% uri %]/p
pfile: [% file %]/p
ppath: [% path %]/p
ptemplate: [% tt %]/p
[% PROCESS footer.html %]
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 COK 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 CApache::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 Ihttpd.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. CApache::ShowRequest uses the CPATH_INFO to get to the URI that should be executed. So to run I/index.html with CApache::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
