> [Followup to my own post; I did some digging and now understand why my > app works under TDK2 but not Tomcat; perhaps this in the archive will > help others who encounter this. I expect it will most often bite > people working on things like the Commons "httpclient", or proxies.] > > I was using PathInfo to hold URLs my app wants to proxy. I found that > multiple slashes, like > > http://localhost:8080/gov.nasa.hq.sna.intranetbroker.Proxy/http://example.co m > > got transmogrified to collapse the double-slash: > > http://localhost:8080/gov.nasa.hq.sna.intranetbroker.Proxy/http://example.co m > > I tried a workaround to url-encode my target URL, but Tomcat rejected > the URI early on, logging the rejection to catalina_log: > > 2002-03-06 23:53:43 HttpProcessor[58080][4] Invalid request URI: > '/sna/servlet/gov.nasa.hq.sna.intranetbroker.Proxy/http%3A%2F%2Fexample.com' > > catalina/src/share/org/apache/catalina/connector/http/HttpProcessor.java > class version 1.29 added a collapse the slashes, transform dot-slash > and backslash types of strings. This is responsible for my first > problem. > > Version 1.30 added the change which causes it to reject URL-encoded > slashes, along with dots, backslashes, and percents. This is > responsible for the second problem. > > > I expect these were both done to prevent URL-based attacks which might > cause the server to wander around the filesystem where it's not > supposed to be. Unfortunately, it breaks my app even though I'm not > accessing the filesystem -- just trying to proxy to other sites.
Only in part. It was also a big security hole for mapping and security constraints (you could bypass authentication and access protected areas using '/' encoding). BTW, you have to encode '/' and ':' in your URI, as you did in the second case. The first URL with unencoded special chars is invalid (ie, it may work, but it's not sure). > These changes have deeper implications for folks writing HTTP clients > and proxies. If the client's desired target URL has any of the > characters [/\.%] in them and they've been URL-encoded (perhaps > by the previous page on the target server) the entire URI will be > rejected. Similarly, if it has unencoded sequences of these (like the > double-slash) the target URL will be damaged. I understand, but this won't be fixed in 4.0.x, as it is way too risky. We could consider fixing it in 4.1, since we'll have the benefit of going through a whole beta phase. > I'm not sure what the answer is. I don't know what types of problems > this normalization is designed to prevent. Perhaps the normalization > could be made more conservative, changing only the part up to the > ContextPath and ServletPath, and leave PathInfo and QueryString > unchanged. Is there anything I could do to help here? I'm not a > stud Java coder, but I'd be happy to contribute. Remy -- To unsubscribe: <mailto:[EMAIL PROTECTED]> For additional commands: <mailto:[EMAIL PROTECTED]> Troubles with the list: <mailto:[EMAIL PROTECTED]>
