tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: getRequestURI() in relation to Connector.URIEncoding
Date Sun, 17 Feb 2013 22:57:27 GMT
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
>>> (
>>> -> RFC 2396 part 2. URI Characters and Escape Sequences
>>> (
>>> 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?

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:
For additional commands, e-mail:

View raw message