2014-06-16 22:38 GMT+04:00 Jimmy Royer <jimlero...@gmail.com>: > On Sun, Jun 15, 2014 at 8:01 AM, Konstantin Kolinko > <knst.koli...@gmail.com> wrote: >> 2014-06-09 17:38 GMT+04:00 Konstantin Kolinko <knst.koli...@gmail.com>: >>> >>> (...) >>> >>> Servlet API javadocs: >>> http://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpServletRequest.html >>> >>> It does not mention explicitly whether getRequestURL() returns a >>> non-decoded or decoded URL, >>> >>> but as our implementation in o.a.c.connector.Request does >>> "url.append(getRequestURI());" I would say that it is expected to >>> return a non-decoded String. >>> >> >> To correct myself here, several notes >> >> 1. getRequestURI() returns just what was sent by the client. >> It is just raw bytes. There is no saying that it is url-encoded. >> It is just that clients do url-encode it to pass it on the wire. >> >> 2. In case of RequestDispatcher.forward(..) the javadoc >> for getRequestURL() says that it "must reflect the path used to obtain >> the RequestDispatcher". >> >> The "history" section of Servlet 3.1 spec (section A.7.3 page 225/240) >> mentions when that method was clarified by adding that requirement. >> >> There is no such requirement for getRequestURI() method. Should its >> value be updated on forwards? The implementation in Tomcat does update >> requestURI on forwards. >> >> 3. If getRequestURL() has to perform an url-encoding of forwarded >> path, it should be noted that url-encoding procedure yields different >> results depending on the character encoding used to convert chars to >> their byte codes. >> >> The usual convention nowadays is to use UTF-8, though I would say >> that it would be more correct to ask the Connector for its URIEncoding >> setting. >> (So that when browser follows a redirect and sends its next request, >> the URL has to be correctly parsed by the Connector. I mean that >> getRequestURL() method is documented as "for creating redirect >> messages".) >> >> In the OP case the trouble was with space characters (%20). > > Just to make it clear and validate my understanding: the space encoding > is part of the URI encoding specification and not related to UTF-8 or other > character encodings. The percentage encoding is a way to escape characters > in the URI. The space characters encoding such as %20 could itself be > encoded in UTF-8 or ASCII. Does that sound right?
Yes, that sounds right. BTW, the java.net.URI class in Java 7 is documented to follow RFC 2396 specification. The current specification on URI syntax is RFC 3986. Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
