tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <>
Subject Re: RewriteRule rewrites, but mod_jk persists with old URI
Date Tue, 15 Jun 2010 18:25:15 GMT

On 15.06.2010 20:08, André Warnier wrote:
> Rainer Jung wrote:
>> On 15.06.2010 16:13, Tobias Crefeld wrote:
>>> Am Tue, 15 Jun 2010 15:04:01 +0200
>>> schrieb André Warnier<>:
>>>> In other words, it appears to receive the URI "/mir/search.jsp", try
>>>> to map it to a worker, succeed, but then forwarding the request to
>>>> Tomcat as "/jsp/search.jsp" anyway (which was the original URL, not
>>>> the rewritten one). This "/jsp/search.jsp" is indeed not found by
>>>> Tomcat (because in Tomcat it is "/mir/search.jsp"), and I receive in
>>>> return a 404 error page from Tomcat.
>>> I'm not quite sure whether I have understood your problem but maybe
>>> this additional setting (after JkMount) helps:
>>> JkOptions +ForwardURIProxy
>> Right, the Forward* JkOptions are the key here. There have been
>> various attempts during the lifetime of mod_jk to try getting this
>> right, so there are various possible options. Finally because of
>> security problems, ForwardURIProxy was introduced in 1.2.24 and made
>> the new default.
>> explains the options and also the limitations with respect to
>> mod_rewrite. There's also a short note at
>> It is possible, that you have explicitely configure
>> ForwardURICompatUnparsed, i.e. please forward the original URI without
>> any interpretation, decoding etc. Since decoding cannot be undone,
>> this means any rewriting by mod_rewrite is not respected. This option
>> was only default at the exact version 1.2.23 but it existed as an
>> option in 1.2.18.
> Hi.
> Thanks to both for your suggestions and explanations.
> The version of mod_jk on that system is 1.2.18, and
> I have not any of the JKOptions Forward* configured in my setup, which
> is just this :
> JkWorkersFile /etc/apache2/
> JkLogFile /var/log/apache2/mod_jk.log
> JkLogLevel debug
> JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "
> Anyway, adding
> JkOptions +ForwardURICompat
> works !
> (which is strange, because the docs says it should be the default before
> 1.2.22)
> Now I'll see if I can get a more recent mod_jk as a Debian package, and
> else I'll see if I can make one myself, so that I can use the latest
> default ForwardURIProxy.
> I also did not understand the reason why in the docs it says "This is ..
> not safe if you are using prefix JkMount."
> Anyone care to elaborate ?
> I am not using "prefix JkMount" specifically, but I am using
> <Location "/mir">
> SetHandler jakarta-servlet
> </Location>
> Does this un-safeness apply in that case also ?

The problem is, that ForwardURICompat forwards the URL as decoded by 
Apache, e.g. usual percent encoding gets resolved. Tomcat decodes again.

So lets construct a URL like


and so some encoding:


Now if Apache gets this URK, it first decodes it


and then normalizes it,


Likely you don't have a JkMount /privateapp or a SetHandler in a 
Location /privateapp. OK, works.

*Now*: Let's double encode:


Apache will decode (once) to


As a decoded URL. Now there's no ".." in it, so normalization doesn't 
change anything and the URL will match JkMount /publicapp/* or Location 

Since ForwardURICompat is in use, mod_jk will forward this URL, so 
Tomcat gets the URL


and decodes *again* resulting in


normalizes to


and serves your private data although you didn't map it in mod_jk.

So double decoding is desaster. That's why we now reencode every 
problematic character before forwarding to Tomcat.

So: depending on your Location URL the warning *does* apply.



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message