perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clément OUDOT <>
Subject Re: [mp2 ] Request output filters and directories
Date Tue, 22 Mar 2011 21:14:29 GMT
2011/3/22 Torsten Förtsch <>:
> On Tuesday, March 22, 2011 15:43:07 Clément OUDOT wrote:
>> Can this behaviour comes from the DirectoryIndex and mod_dir?
> I assume you call add_output_filter in My::Package?


thanks for the answer. Indeed, My::Package call a module like the
following, and the add_output_filter method is called in the run()
subroutine :

> Now, mod_dir uses subrequests for all of your DirectoryIndex documents. The
> first it finds, it redirects to using ap_internal_fast_redirect(). This is a
> very hackish function that tries to magically turn the subreq into the main
> request. It copies a bunch of values from the subreq into the main req. One of
> these values is the output filter list. So, after the operation your main req
> looks mostly like the subreq.
> Another detail that hits you here is that the HeaderParser phase is called
> only for the main request.
> Now put these two together, you start a request for dir/. My::Package installs
> the output filter in its header parser phase. mod_dir jumps in and issues a
> subreq for dir/ The subreq skips the header parser phase.
> ap_internal_fast_redirect copies the output filter chain (without your filter)
> from the subreq to the main one. Your registry script is evaluated
> but the output filter is gone.
> What could be done? I think the cleanest way would be to either move
> My::Package to another phase, fixup for example. If that's not possible you
> can set a flag in $r->pnotes when the filter in installed. Then you need a
> fixup handler that looks if the flag is set in $r->main->pnotes and reinstalls
> the filter if so.

I tried to use PerlFixupHandler instead of PerlHeaderParserHandler,
but this changes nothing. I will try to create a specific FixupHandler
like you suggested.


View raw message