Return-Path: X-Original-To: apmail-perl-modperl-archive@www.apache.org Delivered-To: apmail-perl-modperl-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id E6E639DBC for ; Tue, 26 Jun 2012 09:21:37 +0000 (UTC) Received: (qmail 33734 invoked by uid 500); 26 Jun 2012 09:21:36 -0000 Delivered-To: apmail-perl-modperl-archive@perl.apache.org Received: (qmail 33705 invoked by uid 500); 26 Jun 2012 09:21:36 -0000 Mailing-List: contact modperl-help@perl.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list modperl@perl.apache.org Received: (qmail 33679 invoked by uid 99); 26 Jun 2012 09:21:36 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 26 Jun 2012 09:21:36 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of aw@ice-sa.com designates 212.85.38.228 as permitted sender) Received: from [212.85.38.228] (HELO tor.combios.es) (212.85.38.228) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 26 Jun 2012 09:21:28 +0000 Received: from [192.168.245.129] (p549E8DBF.dip0.t-ipconnect.de [84.158.141.191]) by tor.combios.es (Postfix) with ESMTPA id 41F6ADA041F for ; Tue, 26 Jun 2012 11:21:04 +0200 (CEST) Message-ID: <4FE97EFE.3060501@ice-sa.com> Date: Tue, 26 Jun 2012 11:21:02 +0200 From: =?ISO-8859-1?Q?Andr=E9_Warnier?= Reply-To: mod_perl list User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mod_perl list Subject: Re: Applying mod_perl filters to content served from JBOSS References: <21D67EEA74BD63488C141EA22B514AEA5629BA@BANGMAIL01.sapient.com> In-Reply-To: <21D67EEA74BD63488C141EA22B514AEA5629BA@BANGMAIL01.sapient.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Rommel Sharma wrote: > Hi All, > > > > I have set up mod_perl filtering as follows: > > > SetHandler modperl > PerlOutputFilterHandler MyOutputHandlers::CustomFilterResponse > allow from all > > > staticweb is under htdocs and jbossweb is an app-context deployed in jboss . > > All I am doing is read the response and replace certain strings and send that to the client making the request. > > It is not working for pages being served from jboss (routed to it via the apache web server, using mod_jk) whereas it is working just fine for pages served from Apache's htdocs (being filtered as expected) and access is fine for jboss pages that are not under the filter Location. > Hi. I think that your problem here is that by specifying SetHandler modperl you are contradicting one of your JkMount ... directives, and thus these URLs are no longer being forwarded to Tomcat. In detail : Part 1 : Have a look at this page : http://tomcat.apache.org/connectors-doc/reference/apache.html and in particular, the section entitled : Using SetHandler and Environment Variables What it tells you, is that instead of using directives like this : JkMount /jbossweb myworker JkMount /jbossweb/* myworker you can use SetHandler jakarta_servlet ... to the same effect. They are equivalent. Personally, I prefer the syntax, rather than the JkMount/JkUnMount, because : - if "fits" better with the usual Apache configuration style - it is clearer in terms of the "precedence" aspect of JkMount over other Apache directives - it is easier to combine with other Apache-based things, just like you are trying to do here, to combine it with a mod_perl filter But as a side-effect, you can see how specifying SetHandler jakarta_servlet or SetHandler modperl are mutually exclusive. By saying "SetHandler xxx", you are telling Apache that, to generate the *response* to this HTTP request, it should call the module "xxx". So, it can be *either* jakarta_servlet (forward this request to Tomcat through mod_jk and have Tomcat generate the response) *or* modperl (let the embedded perl interpreter generate the response, by running whatever perl module is configured as the PerlResponseHandler) Part 2 : In your case, you probably do not need to specify SetHandler modperl in order to run you filter. As far as I know, you need "SetHandler modperl" only, if the response itself is generated by a perl module. Which is not the case here, as you want Tomcat/jboss to generate it. So what I would do in your case is : a) remove any "JkMount /jbossweb ..." that you may have b) add a section as follows : SetHandler jakarta_servlet PerlOutputFilterHandler MyOutputHandlers::CustomFilterResponse allow from all If you have any "JkUnmount" related to that same area, then replace them by lines like SetEnvIf REQUEST_URI ^/jbossweb/([^/]*)/static no-jk as indicated in that same Tomcat Connector documentation page What you are doing above is telling Apache : - for any request URL that looks like "^/jbossweb" .. - pass this request to Tomcat, via mod_jk, to generate the response page - and when the Tomcat response page comes back (from mod_jk), and before sending it back to the browser, pass it through my filter module mod_perl advocacy section : You are touching here one of the really interesting aspects of using mod_perl with Apache : you can precisely (like with a surgical scalpel) insert your own module in exactly the appropriate point of the Apache request handling cycle, and combine it with other things which are not mod_perl based. Similarly, you could have inserted other mod_perl things in the request cycle, like Order allow,deny Allow from 1.2.3.4 PerlAuthenHandler MyHandlers::MyAAAHandler->authenticate PerlAuthzHandler MyHandlers::MyAAAHandler->authorize require valid-user SetHandler jakarta_servlet PerlOutputFilterHandler MyOutputHandlers::CustomFilterResponse allow from all and done the access control by Apache, then the user authentication and authorization using your own modules, then let the response be generated by tomcat/jboss, and filter the response when it comes back.