1.39 KB, text/plain
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0 In a web Java servlet-based web application, URLs of the form http://host/test/testServlet work fine and pass the current session token (in a cookie, I presume) to the application. If the URL if of the form http://host\test\testServlet, the proper servlet is invoked, but the session token is not sent. Reproducible: Always Steps to Reproduce: 1. Create a simple stateful test servlet that puts a bean of some sort in the session 2. Access the servlet using its path with '/' characters, and verify that request.getSession().getAttribute("beanName") works. 3. Alter the path substituting '\' for '/' and note that the servlet is invoked, but the bean will not be in the session. (A new one was created, I assume). Actual Results: request.getSession().getAttribute("beanName") returned null because the correct session was not associated with the call. Expected Results: request.getSession().getAttribute("beanName") should return the bean that was placed in session previously.
Created attachment 328658 [details] Wireshark examples of good and bad requests (plain text) It is indeed the missing JSESSIONID cookie.
an "\" in an URL is invalid and must be escaped.
Nevertheless, the '\' gets interpreted by tomcat as '/' and directs the request to the correct servlet. I hate to say it, but IE works as expected.
that IE works doesn't surprise because IE accepts \ as valid which is wrong according to the http RFCs. Which Path is set for the cookie because /testapp/servlet/viewAttachmentServlet?id=1 (Path= /testapp/servlet/) is not the same path as /testapp%5Cservlet%5CviewAttachmentServlet?id=1 (Path= /)
I understand that it's behaving according to spec. I guess it would make more sense to me if Tomcat didn't also interpret the 'invalid' path as pointing to the correct servlet. They apparently decided to accept '\' as a path separator. It's your call whether you want to make a change for compatibility's sake. I'm ok either way. Thanks!
You are not the first one with a backslash problem and the answer is always that a backslash can not be used as separator based on the RFCs. If you allow for a backslash then people want more like "c:\test\test.html" should be a valid URL instead of "file:///c:/test/test.html". I will mark this bug invalid and follow the other bug reports about a backslash in an URL as separator
Status: UNCONFIRMED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.