It seems that Tomcat 5.0.28 (at least) fails to track session using URL rewriting (whith no cookies), when the client converts the reserved characters ; and = in a rewritten URL, rendering what was supposed to be ;jsessionid= as %3Bjsessionid%D. I had a look at RFC 2396, but did not figure out, wether URL encoding in path part of URI is valid. Is it?
The client needs to preserve path parameters, otherwise it will not work.
(In reply to comment #1) > The client needs to preserve path parameters, otherwise it will not work. I'm well aware of that. Question was: by performing an URL encoding on reserved characters ; and :, it the client actually doing something illegal or should tomcat be able to handle it?
';' is reserved, because it is used to define path parameters (such as the session id). If it is encoded, it becomes a regular part of the URI.
(In reply to comment #3) > ';' is reserved, because it is used to define path parameters (such as the > session id). If it is encoded, it becomes a regular part of the URI. Okay, thank you for clearing that out.
I've verified with 5.0.28 and Tomcat DOES unescape %3b (;) and %3d (=) before extracting ;jsessionid= I don't understand what was tested by the person who opened this bug. Maybe the problem was with the %D in the example... It should be %3D, so I believe his test was incorrect. It's very simple to test using the session example (assume session 1A1D98B86F2E813CC27BDCC214C73285 is already created): $telnet localhost 8080 GET /servlets-examples/servlet/SessionExample%3Bjsessionid%3D1A1D98B86F2E813CC27BDCC214C73285 HTTP/1.1 Host: localhost HTTP/1.1 200 OK Content-Type: text/html;charset=ISO-8859-1 Content-Length: 1285 Date: Fri, 16 Dec 2005 20:18:20 GMT Server: Apache-Coyote/1.1 <html> <body bgcolor="white"> <head> <title>Sessions Example</title> </head> <body> <a href="../sessions.html"> <img src="../images/code.gif" height=24 width=24 align=right border=0 alt="view code"></a> <a href="../index.html"> <img src="../images/return.gif" height=24 width=24 align=right border=0 alt="return"></a> <h3>Sessions Example</h3> Session ID: 1A1D98B86F2E813CC27BDCC214C73285 <br> Created: Fri Dec 16 15:13:30 EST 2005<br> Last Accessed: Fri Dec 16 15:13:52 EST 2005 <P> The following data is in your session:<br> foo = bar<br> <P> <form action="SessionExample;jsessionid=1A1D98B86F2E813CC27BDCC214C73285" method=POST> Name of Session Attribute: <input type=text size=20 name=dataname> <br> Value of Session Attribute: <input type=text size=20 name=datavalue> <br> <input type=submit> </form> <P>GET based form:<br> <form action="SessionExample;jsessionid=1A1D98B86F2E813CC27BDCC214C73285" method=GET> Name of Session Attribute: <input type=text size=20 name=dataname> <br> Value of Session Attribute: <input type=text size=20 name=datavalue> <br> <input type=submit> </form> <p><a href="SessionExample;jsessionid=1A1D98B86F2E813CC27BDCC214C73285?dataname=foo&datavalue=bar" >URL encoded </a> </body> </html> </body> </html> I totally agree with Remy analysis regarding preserving reserved characters in the URI (http://www.ietf.org/rfc/rfc2396.txt). I'm reopening the bug because I believe that tomcat should have failed retrieving session when URI is encoded as above. Considering Tomcat is a reference implementation, I would have expected a strict behaviour. Weblogic 8.1 and WebSphere Application Server 5.1.1.7 do not unescape the path portion and path parameters of the URI. It is wrong for a HTTP User agent to encode reserved characters in a URI placed in a document (i.e. HTML, VoiceXML, etc.). Believe it or not, I'm using a VoiceXML platform embedding two different HTTP user agents that have this problem. argh!
Downgrading priority because the behavior is more lenient (i.e. works when *maybe* it shouldn't) instead of being broken when it should work. Jean-Philippe, thank you for your explanation of the issue. If you could test this issue on 5.5.16 or 5.5.17 and inform us of your findings, that'd be great.
The root cause of this is the same although the observed effects are very different. I have tested using the servlet examples and the behaviour is now correct. *** This bug has been marked as a duplicate of 36905 ***