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 ?
