On 17.02.2013 23:00, 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?
Now you throw in another component in the mix. mod_jk is not using HTTP as a protocol to talk to Tomcat and the protocol decoding is not identical with the HTTP one. Before saying such binary URLs are invalid someone would need to check the AJP protocol and the protocol parser in Tomcat about this. I doubt that such URLs are invalid - not based on any code inspection, but simply on the fact that mod_jk decoded percent encoding before forwarding for a long time (5.5 years, from Oct. 2001 to May 2007, version 1.2.0 to 1.2.22). Since version 1.2.24 any bytes in the URI expected to be unsafe are percent encoded before forwarding. At least that's the default. If you use an non-default ForwardURIxxx option via "JkOptions", then that behavior depend on the chosen setting. Nevertheless it makes sense to check and clarify. Which mod_jk version and JkOptions are you using? Can you give a real example of the original URI, the URI that mod_jk forwards (JkLogLevel debug will show it, but that's not meant for production) and how that forwarded URL should look like instead? Regards, Rainer --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
