Torsten Förtsch wrote:
On 12/15/2012 01:30 PM, André Warnier wrote:
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 ?
Perhaps that was the reason for ->add_config instead of ->handler. The
former sets the handler at the point in the request cycle when
SetHandler works, which I think is fixup. The latter acts at the point
of the call.
The point here is that modperl's PerlFixupHandler is registered with
APR_HOOK_REALLY_FIRST meaning it is called before (almost) all other
handlers. So, even if you use ->handler to set the handler to modperl
another module may decide to override your decision.
There is another glitch with mod_proxy here. A normal response handler
checks the content of ->handler to see if it is responsible to generate
the response. Not so mod_proxy. It relies on ->proxyreq:
In fact, where other modules do something like this to decide if they
are to generate the response:
if(strcmp(r->handler, CGI_MAGIC_TYPE) &&
strcmp(r->handler, "cgi-script"))
return DECLINED;
mod_proxy does this:
/* is this for us? */
if (!r->proxyreq || !r->filename ||
strncmp(r->filename, "proxy:", 6) != 0)
return DECLINED;
I think what you want to do is to reconfigure a request previously set
up to be handled by mod_proxy, right? So, in that case you have to
either reset $r->proxyreq to 0 or reset $r->filename to NULL or to
change $r->filename to not start with "proxy:".
YES, resetting $r->filename() does it.
Just for the sake of it, I forced it to the URL of my login page(*), and it doesn't proxy
anymore.
Thanks.
Now I'll study the info above, to really try to understand what's going on.
(*) which I know is wrong, but since I retrieve the login page myself in the
ResponseHandler, I figured it didn't matter.
