You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by André Warnier <aw...@ice-sa.com> on 2007/09/24 16:03:15 UTC

PerlResponseHandler + mod_jk

Context : Apache2, mod_perl2, Tomcat, mod_jk1.2

In an Apache2/Tomcat5 setup, I have the following configuration directives :

<IfModule mod_jk.c>
   # - URI's corresponding to calls to the X servlet are redirected to 
tomcat via the mod_jk module
	JkMount /xyz ajp13
	JkMount /xyz/* ajp13
</IfModule>

But, I would like some of the above URL request to be pre-processed by a 
mod_perl handler, like

<Location /xyz>
   SetHandler perl-script
   PerlResponseHandler My::module
   PerlSetVar anyvar "anyvalue"
</Location>

My::module would do something (or not) to the request, then it should 
let the (possibly modified) request go through, so that the mod_jk 
module can intercept it and re-direct it to Tomcat.

The problem is that I can *either* have one or the other configuration 
snippet above, but if I try both, then the request is always 
"short-circuited" by the mod_jk module (and re-directed to Tomcat), and 
the mod_perl handler is never executed.  Or vice-versa I think, 
depending on which comes last.

I have found one solution, which is to install the mod_perl handler as a 
PerlAccessHandler, as such :

<Location /xyz>
   PerlAccessHandler My::module
   PerlSetVar anyvar "anyvalue"
</Location>

In this way, the mod_perl handler is executed in an earlier Apache phase 
than the mod_jk intercept.  It works fine, but since the function of the 
module has basically not much to do with Access Control, I wonder if 
there is not a  more elegant way to do this.

I guess it boils donw to the following more generic question :
Assuming that the Apache configuration would already specify some 
(non-perl) handlers for some Location, Directory or whatever, is there a 
way to "insert" mod_perl handlers in the chain, without overriding the 
other handlers ?
And if yes, what does the mod_perl handler need to return to insure that 
the other handlers run also (OK, DECLINED,..) ?

Anyone has an idea ?

Thanks in advance
aw

Re: PerlResponseHandler + mod_jk

Posted by Perrin Harkins <pe...@elem.com>.
On 9/25/07, André Warnier <aw...@ice-sa.com> wrote:
>  From what I understand of the documentation, by the time we get to the
> input filter, we are already at the Response stage, which means all the
> stuff about interpreting the headers, and assigning the request to
> mod_jk, is already done. No ?

No.  http://perl.apache.org/docs/2.0/user/handlers/filters.html#HTTP_Request_Versus_Connection_Filters

> The mod_jk "re-direction" is specified in httpd.conf by the following
> kind of config lines :
>
> <IfModule mod_jk.c>
>      JkMount /xyz ajp13
>      JkMount /xyz/* ajp13
> </IfModule>

You'll have to find out what the JkMount directive does.  It probably
just sets a few Location mappings for you.  Ask the mod_jk list.

- Perrin

Re: PerlResponseHandler + mod_jk

Posted by André Warnier <aw...@ice-sa.com>.
Perrin Harkins wrote:
> On 9/24/07, André Warnier <aw...@ice-sa.com> wrote:
>> My::module would do something (or not) to the request, then it should
>> let the (possibly modified) request go through, so that the mod_jk
>> module can intercept it and re-direct it to Tomcat.
> 
> Your should write your code as an input filter then, not a response handler.
> 

Sorry, I was not quite clear in what I meant by "modifying the request". 
  I meant modifying stuff like the incoming HTTP headers or the URI, not 
the content.

 From what I understand of the documentation, by the time we get to the 
input filter, we are already at the Response stage, which means all the 
stuff about interpreting the headers, and assigning the request to 
mod_jk, is already done. No ?
I get the impression that the input filter, contrary to handlers, is a 
kind of "pull" module : it is invoked when (in this case) mod_jk reads 
the request content, and gets to see (and possibly modify) the input 
stream (buckets) of mod_jk on-the-fly.
Can an input filter then still modify the request, in the sense for 
example of changing the request URI or adding/modifying incoming request 
HTTP headers, or is it then too late for that ?

But assuming it can, there is another area which is still not clear to 
me. I realise that this is not a specifically mod_perl question, but 
would anyone happen to know ?

The mod_jk "re-direction" is specified in httpd.conf by the following 
kind of config lines :

<IfModule mod_jk.c>
     JkMount /xyz ajp13
     JkMount /xyz/* ajp13
</IfModule>

That seems like a "server-level" specification, outside of any 
<Location> or <Directory> section.  On the other hand, a 
PerlInputFilterHandler is a Directory-level specification. How would I 
specify a mod_perl input filter for those same URI's ?
I don't know how to express this more clearly.  I guess it would be 
clearer if the mod_jk directives were expressed as
<Location /xyz>
   JkMount ajp13
</Location>
and I could just insert the PerlInputFilterHandler in that same section,
but that's not how the mod_jk documentation says to do it.

aw


Re: PerlResponseHandler + mod_jk

Posted by Perrin Harkins <pe...@elem.com>.
On 9/24/07, André Warnier <aw...@ice-sa.com> wrote:
> My::module would do something (or not) to the request, then it should
> let the (possibly modified) request go through, so that the mod_jk
> module can intercept it and re-direct it to Tomcat.

Your should write your code as an input filter then, not a response handler.

- Perrin