perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: setHandler question
Date Sat, 15 Dec 2012 12:30:58 GMT
Torsten Förtsch wrote:
> On 12/14/2012 02:52 PM, André Warnier wrote:
>> Or am I totally off-track here ?
> 
> I think yes, you are confused by the similarity of "finfo" and
> "OR_FILEINFO".

Yes, I was. Thanks for setting me right.

> 
> The finfo part of $r is simply a data structure that represents the
> metadata of a file on the filesystem such as modification dates, access
> rights, the size and whether it is a regular file, directory, socket or
> something else.
> 
> A standard request for a static file in Apache works as follows. In the
> MapToStorage phase the request URI is mapped to a file (or directory) on
> the filesystem (by means of DocumentRoot, Alias and the like). Then also
> in the MapToStorage phase Apache performs a stat(2) call on the resolved
> file name. The result is stored in $r->finfo.
> 

Ok. Then, in my case I have

<LocationMatch "/IIS_app/(.*)$">
   PerlAuthenHandler SLC->authenticate
   PerlAuthzHandler SLC->authorize
   PerlSetVar SLC_login_page "/public/login.html"
   ...
   ProxyPassMatch http://localhost:8800/$1
</LocationMatch>

"/IIS_app/" does not map to anything on the filesystem.
I guess then that $r->finfo should not contain anything, or at least nothing related to
a 
disk file.  And neither $r->filename();

> Then in the response phase the information stored in finfo is used to
> set up the Content-Length header as well as the cache control headers
> like Etag and Last-Modified.
> 

So nothing here that is relevant, as these headers would normally be generated by IIS.

> OR_FILEINFO on the other hand is simply a flag that represents the
> "FileInfo" flag in the "AllowOverride" directive:
> 
>   http://httpd.apache.org/docs/2.2/mod/core.html#allowoverride
> 
> Modperl's $r->add_config acts more or less like a .htaccess file. In
> this context the "SetHandler" directive needs "AllowOverride FileInfo"
> to be in effect. See
> 
>   http://httpd.apache.org/docs/2.2/mod/core.html#sethandler
> 
> Unlike a .htaccess file, $r->add_config expects the override bits as the
> next parameter after the list of configuration directives.
> 
> So, to be able to set the handler by means of
> 
>   $r->add_config(['SetHandler ...'])
> 
> you have to pass along a set of override bits that includes OR_FILEINFO.
> That means for example
> 
>   $r->add_config(['SetHandler ...'], OR_FILEINFO)
> 
> or even
> 
>   $r->add_config(['SetHandler ...'], ~0)
> 
> since ~0 is an integer with all bits set.
> 
> I can't remember why I hinted at $r->add_config instead of
> $r->handler('newhandler') at the time of the first discussion. Perhaps
> there was a reason (like the wrong request phase), perhaps I had a blackout.
> 
Perhaps. But you are forgiven, since I think that it was with the best of intentions anyway.

My basic question is that I am setting
$r->handler('modperl');
in the PerlAuthenHandler above, and neither Apache nor mod_perl complain.  But it does not

stop Apache from proxying the call anyway.
Even if (as per one of your earlier suggestions), I do (or repeat) this 
$r->handler('modperl'); in a Fixup handler.

Why is that ?
Does mod_proxy somehow have still some "priority" as compared to the mod_perl handler ?
Does mod_proxy do something earlier in the cycle that causes the $r->handler() to 
(silently) have no effect later ?

> I hope you understand now that "OR_FILEINFO" and "finfo" are completely
> unrelated things. The only thing they have in common is a certain
> similarity in their names.

Yes, I understand that now.  My confusion came from imagining that the MapToStorage phase

(subverted ny mod_proxy) might put something in the $r->finfo, that would cause the effect

later.



I know that I can do this via either an ErrorDocument, or via the call to
$r->add_config(['SetHandler ...'], OR_FILEINFO).

But my current code is not really suited to do it via an ErrorDocument.

And somehow the $r->add_config() looks a bit like a roundabout way of achieving what I

want.  If I can, kind of, "stuff" an additional SetHandler configuration directive into 
the Apache configuration for my request, telling Apache "now do as if the <Location>

contained a SetHandler directive", then why does the simpler $r->setHandler() not work
?



Mime
View raw message