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<a...@ice-sa.com>:
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.
http://tomcat.apache.org/connectors-doc/reference/apache.html#Forwarding
explains the options and also the limitations with respect to
mod_rewrite. There's also a short note at
http://tomcat.apache.org/connectors-doc/generic_howto/proxy.html#URL%20Encoding
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/workers.properties
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
/publicapp/../privateapp/privatedata
and so some encoding:
/publicapp/%2E%2E/privateapp/privatedata
Now if Apache gets this URK, it first decodes it
/publicapp/../privateapp/privatedata
and then normalizes it,
/privateapp/privatedata
Likely you don't have a JkMount /privateapp or a SetHandler in a
Location /privateapp. OK, works.
*Now*: Let's double encode:
/publicapp/%252E%252E/privateapp/privatedata
Apache will decode (once) to
/publicapp/%2E%2E/privateapp/privatedata
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
/publicapp.
Since ForwardURICompat is in use, mod_jk will forward this URL, so
Tomcat gets the URL
/publicapp/%2E%2E/privateapp/privatedata
and decodes *again* resulting in
/publicapp/../privateapp/privatedata
normalizes to
/privateapp/privatedata
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.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
