'Re: problems with DirectoryIndex under mod_perl + Template Toolkit'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       apache-modperl
Subject:    Re: problems with DirectoryIndex under mod_perl + Template Toolkit
From:       "Tim Noll" <tnoll () grapevine ! net>
Date:       2002-01-31 15:30:41
[Download RAW message or body]

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" <stas@stason.org>
To: "Tim Noll" <tnoll@grapevine.net>
Cc: <modperl@apache.org>; <templates@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/
>
>
>

[prev in list] [next in list] [prev in thread] [next in thread]
Configure | About | News | Add a list | Sponsored by KoreLogic