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? Best regards Mike --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
