You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Clément OUDOT <cl...@gmail.com> on 2011/03/22 15:43:07 UTC

[mp2 ] Request output filters and directories

Hi all,

I am one of the developer of LemonLDAP::NG (http://lemonldap-ng.org),
a free WebSSO using mod_perl. So to begin, thanks to the mod_perl team
for this great product!

In our code, we are injecting request output filters with the
add_output_filter method. This works well, but we noticed that the
filter is never called on directories, only on files:
* http://test1.example.com/ -> filter not called
* http://test1.example.com/index.pl -> filter called

I use ModPerl 2.0.4 for my tests. My Apache configuration is the following:

---------------

<VirtualHost *:80>
    ServerName test1.example.com
    ServerAlias test2.example.com

    # SSO protection
    PerlHeaderParserHandler My::Package


    # DocumentRoot
    DocumentRoot /usr/local/lemonldap-ng/htdocs/test/
    <Directory /usr/local/lemonldap-ng/htdocs/test/>
        Order deny,allow
        Allow from all
        Options +ExecCGI
    </Directory>

    # Perl script (application test is written in Perl)
    <Files *.pl>
        SetHandler perl-script
        PerlResponseHandler ModPerl::Registry
    </Files>

    # Directory index
    <IfModule mod_dir.c>
        DirectoryIndex index.pl index.html
    </IfModule>

</VirtualHost>

---------------


Can this behaviour comes from the DirectoryIndex and mod_dir?


Thanks for your help,

Clément OUDOT.

Re: [mp2 ] Request output filters and directories

Posted by Clément OUDOT <cl...@gmail.com>.
2011/3/22 Torsten Förtsch <to...@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.

Re: [mp2 ] Request output filters and directories

Posted by Torsten Förtsch <to...@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?

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.

Torsten Förtsch

-- 
Need professional modperl support? Hire me! (http://foertsch.name)

Like fantasy? http://kabatinte.net