DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9111>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9111 URL encoding fails for relative paths in contexts containing "unsafe" characters Summary: URL encoding fails for relative paths in contexts containing "unsafe" characters Product: Tomcat 3 Version: 3.3.1 Final Platform: PC OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I recently moved from Tomcat 3.2.3 to Tomcat 3.3.1 final. When using a context path containing a '~' character, relative URLs within this context were not properly URL encoded when turning off cookies. Since this had worked up to now with Tomcat 3.2.3, I went searching the source code and found the following in org.apache.tomcat.facade.HttpServletResponseFacade: When calling encodeURL() for a relative URL, it is made absolute based on the request URL retrieved by calling javax.servlet.http.HttpUtils.getRequestURL() on the current request object. Now, with Tomcat 3.3.1 the request object returns an encoded string for getRequestURI(), which is called by HttpUtils internally in getRequestURL(). This is due to the Servlet 2.2 Specification Errata (4/27/00). Before returning the current request URI, which is already decoded, it therefore has to be reencoded by using the org.apache.tomcat.util.buf.UEncoder. UEncoder encodes all characters in a given string with the proper hexadecimal escape sequence except certain "safe" characters which are allowed to be unescaped. These "safe" characters include by default "unreserved" characters as defined by RFC1738. In contrast to the newer RFC2396 this "unreserved" set doesn't include the '~' character. The '~' in our request's path is therefore encoded by '%7e'. Now that the absolute URL for the given relative one is found, it is checked if it contains the current request's context path. If it doesn't, no URL encoding is desired for this URL. But, since this context path is returned unencoded, there is no match between '~' in the context path and '%7e' in the absolute URL to encode. This means that our relative URL is not encoded as it should be. To solve the encountered problem I propose the following patch: Index: src/facade22/org/apache/tomcat/facade/HttpServletResponseFacade.java =================================================================== RCS file: /home/cvspublic/jakarta- tomcat/src/facade22/org/apache/tomcat/facade/HttpServletResponseFacade.java,v retrieving revision 1.28 diff -u -r1.28 HttpServletResponseFacade.java --- src/facade22/org/apache/tomcat/facade/HttpServletResponseFacade.java 22 Mar 2002 02:54:34 -0000 1.28 +++ src/facade22/org/apache/tomcat/facade/HttpServletResponseFacade.java 15 May 2002 07:45:04 -0000 @@ -64,6 +64,7 @@ package org.apache.tomcat.facade; +import org.apache.tomcat.util.buf.UDecoder; import org.apache.tomcat.util.res.StringManager; import org.apache.tomcat.util.http.*; import org.apache.tomcat.core.*; @@ -416,8 +417,9 @@ Request request = response.getRequest(); HttpServletRequestFacade reqF=(HttpServletRequestFacade)request. getFacade(); - String requrl = - HttpUtils.getRequestURL(reqF).toString(); + UDecoder udecoder = request.getURLDecoder(); + String requrl = udecoder.convert( + HttpUtils.getRequestURL(reqF).toString()); try { url = new URL(new URL(requrl), location); } catch (MalformedURLException e2) { It could be more sensible though, to change the way the current request's URL is retrieved, or to change UEncoder to conform to RFC2396. I don't have enough insight into Tomcat code and the underlying specifications to know about possible implications. The patch above worked for me however. Thanks for regarding my proposal. Alex. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
