DO NOT REPLY [Bug 9111] New: - URL encoding fails for relative paths in contexts containing "unsafe" characters

[bu...@apache.org]

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: tomcat-dev@jakarta.apache.org
        ReportedBy: alexander.lamm@livinglogic.de


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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>