clem.oudot at gmail
Mar 22, 2011, 2:14 PM
Post #3 of 3
2011/3/22 Torsten Förtsch <torsten.foertsch [at] gmx>:
Re: [mp2 ] Request output filters and directories
[In reply to]
> 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()
> 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/index.pl. 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 index.pl 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.