tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Roberts <Mike.Robe...@digitalrum.com>
Subject RE: Config Problem : VirtualHost, mod_rewrite and mod_jk
Date Wed, 30 Jan 2002 17:16:00 GMT
Regarding mod_rewrite and Tomcat, has this issue been addressed in Tomcat 4
/ Servlet 2.3? If so, please could someone let me know what the behaviour is
for both mod_jk and mod_webapp as connectors?

Many thanks,

Mike

--
Mike Roberts
Architect
DigitalRum
mailto:mike.roberts@digitalrum.com

----------------------------------------------------------------------------
----

From: Larry Isaacs 
Subject: RE: Config Problem : VirtualHost, mod_rewrite and mod_jk 
Date: Wed, 05 Dec 2001 06:12:36 -0800 

----------------------------------------------------------------------------
----

Hi Geir,

Concerning mod_rewrite, there was a lot of discussion about
what mod_jk should do about the Servlet 2.2's requirement that
HttpServletRequest.getRequestURI() return a URI that *remains*
encoded.  So that it *remains* encoded, the mod_jk in Tomcat 3.2.3
forwards the "unparsed" request to Tomcat.  This prevents
mod_rewrite from having an effect since it modifies the
"parsed" request.

To bring mod_rewrite back online, mod_jk in Tomcat 3.2.4
forwards a re-encoded version of the "parsed" request
(sacrificing "remains" in favor of functionality).

In Tomcat 3.3, this is configurable, though this hasn't
yet made it into the documentation. :(

In the mod_jk configuration file, you can set the following
options to control which request is forwarded to Tomcat.

    JkOptions ForwardURICompat+

forwards the "parsed" URI as is.  Tomcat 3.3 will re-encode
the request for getRequestURI().  This is the default
behavior.

    JkOptions ForwardURICompatUnparsed+

forwards the "unparsed" URI and Tomcat 3.3 will return
this string unmodified for getRequestURI().  This best
matches the spec, but breaks mod_rewrite.  This matches
Tomcat 3.2.3's mod_jk behavior.

    JkOptions ForwardURIEscaped+

forwards the re-encoded "parsed" URI and Tomcat 3.3 will
return this string unmodified for getRequestUR().  This
matches Tomcat 3.2.4's mod_jk behavior.

I'll try to add some documentation concerning this in the
Tomcat 3.3 release.

Hope this helps.

Cheers,
Larry

> -----Original Message-----
> From: Geir Magnusson Jr. [mailto:geirm@optonline.net]
> Sent: Tuesday, December 04, 2001 9:17 PM
> To: Tomcat Users List
> Subject: Config Problem : VirtualHost, mod_rewrite and mod_jk
> 
> 
> I am looking for some tips or advice on a configuration problem :
> 
> I wish to configure Apache with virtual hosts, and along with some URL
> rewriting, and use mod_jk under httpd 1.3.x And Tomcat 3.2.3
> 
> I have successfully configured mod_jk and two <Hosts> in tomcat's
> server.xml, and have verified that mod_jk is working, and the 
> Hosts are
> properly mapping requests to two separate webapps.  So far, so good.
> 
> The problem comes in with mod_rewrite.  This is an update 
> from mod_jserv,
> where 
> 
>   Action action1  /servlet/com.foo.FooServlet
> 
>   <LocationMatch /*.html>
>     SetHandler action1
>   </LocationMatch>
> 
> Was used, and this worked fine.
> 
> When I switched to mod_jk and VirtualHosts, this resulted in 
> recursion,
> constructing a huge URL that Apache coughed up.
> 
> I then switched to mod_rewrite, and was able to (easily) 
> construct a rewrite
> rule to do the same thing.  I used the [P] flag to force it 
> to the proxy.
> 
> The problem is that mod_jk never 'picked up' the rewritten URL.
> 
> I have searched for some information on this, but to no 
> avail.  There were
> references to putting the LoadModule for mod_jk before the 
> LoadModule for
> mod_rewrite, and I have tried that (and reverse) and other 
> orderings of
> mod_jk directives, rewrite directives, in the <VirtualHost>, 
> outside of the
> <VirtualHost> etc.
> 
> Any insight would be greatly appreciated...
> 
> Thanks in advance.
> 
> geir
> 
> -- 
> Geir Magnusson Jr.                       geirm@optonline.net
> System and Software Consulting
> You're going to end up getting pissed at your software
> anyway, so you might as well not pay for it. Try Open Source.
> 
> 

--
To unsubscribe:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
For additional commands: <mailto:tomcat-user-help@jakarta.apache.org>
Troubles with the list: <mailto:tomcat-user-owner@jakarta.apache.org>


Mime
View raw message