2011/3/22 Torsten Förtsch <torsten.foert...@gmx.net>: > 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?
Hi, 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 : http://websvn.ow2.org/filedetails.php?repname=lemonldap&path=%2Ftrunk%2Fmodules%2Flemonldap-ng-handler%2Flib%2FLemonldap%2FNG%2FHandler%2FSecureToken.pm > > 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. Clément.
