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 Sun, 16 Dec 2012 18:29:56 GMT
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é


Mime
View raw message