Mike Wilson wrote:
Mark Thomas wrote:
On 17/02/2013 16:54, André Warnier wrote:
Mike Wilson wrote:
<snip/>
Example 2: path /ä in "binary" Unicode
GET /.. [0xC3,0xA4]
request.getRequestURI() -> "/.." [0xC3,0xA4]
request.getPathInfo() -> "/ä"
<snip/>
I believe that your example #2 above is simply illegal.
One is not supposed to send such bytes in a URL without
URL-encoding them.
That's per the HTTP RFC itself :
RFC 2616 3.2.2 & 3.2.3
(http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2.2)
-> RFC 2396 part 2. URI Characters and Escape Sequences
(http://www.ietf.org/rfc/rfc2396.txt)
And I believe that the fact that Tomcat is returning the "correct"
translation in the corresponding request.getPathInfo() is purely
accidental, and it could be argued that this is a bug in
Tomcat : the
request should probably have been rejected, because the
requested URL
was invalid.
+1. It is on my list of things to do to check why this wasn't
rejected
with a 400 response.
Mark
Explicitly making this invalid is probably fine, although it might
be looked upon as "breaking" working systems. Note that we have
apparently been running with a setup sending these binary URLs
for years, where mod_jk is the source of the invalid URLs.
Ie, the browser sends a nice URL-encoded URL which is decoded by
mod_jk before sending to Tomcat.
So might be appropriate to hold off this change to a release where
back compat isn't crucial?
Mmmm.
It stretches the imagination a bit to imagine that mod_jk by default takes a valid URL and
makes it invalid before forwarding it to Tomcat.
As far as I recall, there are several options in mod_jk (ForwardURI* family) which allow
to do things there, some of them unsafe.
So it raises the question : are you doing something until now which is considered as
unsafe, and therefore are having that problem ?
(And a linked question is whether by changing this mod_jk option you could restore
operability with a Tomcat rejecting the invalid URLs).
Otherwise, my feeling is that it will cost you quite a number of beers to stop Mark from
fixing what could potentially be a security issue, now that he's sniffed it.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
