Re: setHandler question

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.