>> The '+' char has no special meaning in HTTP/1.1 (RFC 2616) [1], so in >> the path part of the URL it just means itself, the plus sign. > > Any bug in either mod_alias or mod_jk could be proven with regard to the > above statement by simply changing the URL from: > > http://localhost/sites/one%2Bone%3Cthree > to: > http://localhost/sites?one%2Bone%3Cthree
Whaddya know - the test results show that Konstantin is right! The query mark makes all the difference, and incidently, '+' seems to be the only character that is being treated differently by the decoder. When presented with a query http://localhost/sites/one%2Bone%3Cthree?one%2Bone%3Cthree mod_alias responds with a redirect to http://localhost/contextroot/subcontext/sites/one+one%3cthree?one%2Bone%3Cthree , leaving the query part intact. mod_jk also behaves in a similar fashion with +ForwardURIProxy. A request to http://localhost/contextroot/subcontext/sites/one%2Bone%3Cthree?one%2Bone%3Cthree shows up as http://localhost/contextroot/subcontext/sites/one+one%3Cthree?one%2Bone%3Cthree in Tomcat's logs. Furthermore org.apache.tomcat.util.buf.UDecoder and org.apache.catalina.util.RequestUtil classes seem to have special handling logic for query parts which enable this kind of checks: if (b == '+' && isQuery) { b = (byte)' '; } else if (b == '%') { b = (byte) ((convertHexDigit(bytes[ix++]) << 4) + convertHexDigit(bytes[ix++])); } I have not yet actually tested this in practice, but look like the facts speak for themselves. I still cannot find this functionality in specs, but it looks like I don't have to. :-) Good job, Konstantin! In the end, the only real bug here seems to reside my application's use of Apache Commons URLCodec. I will have to replace that with some other solution that respects the difference between path and query parts. I should be able to use +ForwardURIProxy as well. It may be a different solution than I expected and it does not make a difference with %2B and '+' characters, but it should work and be spec- (or at least reality-) compliant. :-) I will let you know whether it solves the problem. Tero Karttunen --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
