RewriteRule rewrites, but mod_jk persists with old URI
Hi.
I have a problem at tbe border between Apache httpd's mod_rewrite and the mod_jk
Apache/Tomcat connector.
Versions are :
Apache httpd 2.2.3
mod_jk 1.2.18
OS : Linux Debian 2.6.18-6-686 #1 SMP Thu May 8 07:34:27 UTC 2008 i686
GNU/Linux
(Not the latests versions, I know, but that's what that system has and the problem may not
be version-linked, and there is something sweet about packages which just install/upgrade
with apt-get)
The request URL I am using is
http://hostname/jsp/search.jsp
In the Apache httpd config, is the following RewriteRule :
RewriteCond %{REQUEST_URI} ^/jsp/(.*)$
RewriteRule ^/jsp/ /mir/%1 [PT]
OR, more simply (but with the same result at the end) :
RewriteRule ^/jsp/(.*)$ /mir/$1 [PT]
plus a Location section as follows :
Location /mir
SetHandler jakarta-servlet
/Location
(OR the following, to the same end-effect also :
JkMount /mir ajp13
JkMount /mir/* ajp13
)
The above rewrite rule should rewrite /jsp/search.jsp to /mir/search.jsp
and it does, as per the mod_rewrite log :
[rid#8c06030/initial] (2) init rewrite engine with requested uri /jsp/search.jsp
[rid#8c06030/initial] (2) rewrite '/jsp/search.jsp' - '/mir/search.jsp'
[rid#8c06030/initial] (2) forcing '/mir/search.jsp' to get passed through to next API
URI-to-filename handler
But then, in the mod_jk log, I see this :
...
[Tue Jun 15 11:26:15 2010] [9170:30400] [debug] map_uri_to_worker::jk_uri_worker_map.c
(508): Attempting to map URI '/mir/search.jsp' from 2 maps
[Tue Jun 15 11:26:15 2010] [9170:30400] [debug] map_uri_to_worker::jk_uri_worker_map.c
(520): Attempting to map context URI '/mir/*'
[Tue Jun 15 11:26:15 2010] [9170:30400] [debug] map_uri_to_worker::jk_uri_worker_map.c
(534): Found a wildchar match ajp13 - /mir/*
[Tue Jun 15 11:26:15 2010] [9170:30400] [debug] jk_handler::mod_jk.c (1832): Into handler
jakarta-servlet worker=ajp13 r-proxyreq=0
[Tue Jun 15 11:26:15 2010] [9170:30400] [debug] wc_get_worker_for_name::jk_worker.c (111):
found a worker ajp13
[Tue Jun 15 11:26:15 2010] [9170:30400] [debug] init_ws_service::mod_jk.c (531): Service
protocol=HTTP/1.1 method=GET host=(null) addrr=84.158.163.2 name=(hostname) port=80
auth=(null) user=(null) laddr=192.168.245.20 raddr=84.158.163.2
[Tue Jun 15 11:26:15 2010] [9170:30400] [debug] ajp_get_endpoint::jk_ajp_common.c (2172):
acquired connection pool slot=0
[Tue Jun 15 11:26:15 2010] [9170:30400] [debug] ajp_marshal_into_msgb::jk_ajp_common.c
(566): ajp marshaling done
[Tue Jun 15 11:26:15 2010] [9170:30400] [debug] ajp_service::jk_ajp_common.c (1706):
processing ajp13 with 2 retries
[Tue Jun 15 11:26:15 2010] [9170:30400] [debug]
ajp_connection_tcp_send_message::jk_ajp_common.c (909): sending to ajp13 pos=4 len=424
max=8192
[Tue Jun 15 11:26:15 2010] [9170:30400] [debug]
ajp_connection_tcp_send_message::jk_ajp_common.c (909): 12 34 01 A4 02 02 00 08 48
54 54 50 2F 31 2E 31 - .4..HTTP/1.1
[Tue Jun 15 11:26:15 2010] [9170:30400] [debug]
ajp_connection_tcp_send_message::jk_ajp_common.c (909): 001000 00 0F 2F 6A 73 70 2F 73
65 61 72 63 68 2E 6A - .../jsp/search.j
[Tue Jun 15 11:26:15 2010] [9170:30400] [debug]
ajp_connection_tcp_send_message::jk_ajp_common.c (909): 002073 70 00 00 0C 38 34 2E 31
35 38 2E 31 36 33 2E - sp...84.158.163.
[Tue Jun 15 11:26:15 2010] [9170:30400] [debug]
ajp_connection_tcp_send_message::jk_ajp_common.c (909): 003032 00 FF FF 00 17 6D 69 72
2E 64 65 76 2E 77 69 - 2.mir.dev.wi
...
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 have tried umpteen variations for the mapping and the rewrite rule, without
success.
What am I doing wrong ?
Or, was this a bug in mod_jk 1.2.18, since corrected ?
(But I find nothing that appears relevant in the Changes log at
http://tomcat.apache.org/connectors-doc/miscellaneous/changelog.html)
Thanks
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: RewriteRule rewrites, but mod_jk persists with old URI
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 Gruß, Tobias. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: RewriteRule rewrites, but mod_jk persists with old URI
On 15.06.2010 16:13, Tobias Crefeld wrote: Am Tue, 15 Jun 2010 15:04:01 +0200 schrieb André Warniera...@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. Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: RewriteRule rewrites, but mod_jk persists with old URI
Rainer Jung wrote: On 15.06.2010 16:13, Tobias Crefeld wrote: Am Tue, 15 Jun 2010 15:04:01 +0200 schrieb André Warniera...@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 ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: RewriteRule rewrites, but mod_jk persists with old URI
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é Warniera...@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
Re: RewriteRule rewrites, but mod_jk persists with old URI
Rainer Jung wrote: 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é Warniera...@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 Got it, thanks for your time. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: RewriteRule rewrites, but mod_jk persists with old URI
Am Tue, 15 Jun 2010 20:08:15 +0200 schrieb André Warnier a...@ice-sa.com: The version of mod_jk on that system is 1.2.18, and [..] Now I'll see if I can get a more recent mod_jk as a Debian package, I'm not so familiar with Debian and we run only on sparc-version (5.0, Lenny), but there should be a newer one at the normal repositories: Server Version: Apache/2.2.9 (Debian) mod_jk/1.2.26 $ dpkg-query -p libapache2-mod-jk |head Package: libapache2-mod-jk Priority: optional Section: web Installed-Size: 536 Maintainer: Debian Java Maintainers pkg-java-maintain...@lists.alioth.debian.org Architecture: sparc Source: libapache-mod-jk Version: 1:1.2.26-2+lenny1 Replaces: libapache2-mod-jk2 Depends: libc6 (= 2.7-1), apache2.2-common, apache2 Regards, Tobias. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
