André Warnier wrote:
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.
I also tried the following sequence, and it works just as well :
$r->proxyreq(Apache2::Const::PROXYREQ_NONE);
$r->handler('modperl');
$r->set_handlers(PerlResponseHandler => \&_send_login_form);
And I also tried :
my $dest = $r->filename();
$dest =~ s/^proxy://;
$r->filename($dest);
# $r->proxyreq(Apache2::Const::PROXYREQ_NONE);
$r->handler('modperl');
$r->set_handlers(PerlResponseHandler => \&_send_login_form);
and it also works (with or without the commented $r->proxyreq)
I am in the meantime discussing the same thing with Rainer Jung (developer of the mod_jk
Apache/Tomcat connector module), because in terms of functionality, mod_jk is similar to
mod_proxy. I hope to be able to write some code in the end which covers all cases at once.
And anyway this is fun. Doing things with mod_perl provides a lot of insights in terms of
how Apache httpd works.
Thanks very much for the help.
André
