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:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
