The url I use to access Tomcat is: http://localhost/bin/upload;jsessionid=CDDAB8614E1F0ACB724CC033C8300697 the result I was getting when calling request.getRequestURI() is: /bin/upload This used to work until the latest version of tomcat 6.0.33. Now I'm getting: /bin/upload;jsessionid=CDDAB8614E1F0ACB724CC033C8300697
As I already explained several days ago to somebody else on the users@ list, this behaviour is required by the Servlet specification. See servlet-2_5-mrel2-spec.pdf ch. SRV.3.1, Quote: [[[ Path parameters that are part of a GET request (as defined by HTTP 1.1) are not exposed by these APIs. They must be parsed from the String values returned by the getRequestURI method or the getPathInfo method. ]]]
This might be so, but jsessionid is tomcat specific paramater which only puprose is to provide the session id. By the time getRequestURI gets called it has been extracted and the users doesn't need to know about it. If they need the session id they can get it from the session object. Furthermore Tomcat 6 is considered stable and not in active development any more. Changing the default behaviour because of differnt interpretation of the spcec doesn't seem very stable to me. It might be a big and very unplesent surprise for some users when they discover that their applicatoins which have been in use for years don't work any more after the latest upgrade because of such so belated change of heart.
Tomcat 6 is under active development. It receives security fixes, bug fixes and some new features. Non-compliance with the Servlet specification is always treated as a bug in Tomcat. Failure to return the correct value for getRequestURI() was a bug and has been fixed. An application failure triggered by a valid - as per the specification - return value from getRequestURI() is a bug in the application, not a bug in Tomcat. While backwards incompatible changes are avoided where possible, the Tomcat developers can't predict how every applications may respond to each individual change and in this case specification compliance took precedence over the risk of breaking backwards compatibility which was judged to be extremely low. Where the risk of breaking compatibility is judged to be higher - or subsequently a significant compatibility problem is found - the usual approach is to add a configuration option that permits the previous - normally non-specification compliant - behaviour. In this case I do not see sufficient justification for adding such an option.
Sorry, but this change was registered in release notes and/or change log of 6.0.33 version?
Yes, this is in the change log. If you have any further questions on this change, they belong on the users mailing list.
Some person is currently asking about history of this change on the users@ list, comparing behaviour of some old Tomcat 6 and current Tomcat 7 versions. (2015-07-23, "Tomcat 7 (7.0.54) Login URL is Passing with JSESSION ID. | why there is different behaviour in Tomcat 6 and Tomcat 7" http://markmail.org/message/jdwpyll2nl25me24 ) This change is listed in changelog, but it does not have a bug number with it. I am taking this chance to better document it. This change in changelog of 6.0.33: <fix> Improve handling of URLs with path parameters and prevent incorrect 404 responses that could occur when path parameters were present. (kkolinko) </fix> ************************************************ Comments: 1. The commit for this change: 2011-07-21 http://svn.apache.org/viewvc?view=revision&revision=1149220 "Fix path parameter handling. Prevent the following URL failing with a 404: http://localhost:8080/examples/jsp/snp;x=y/snoop.jsp" 2. The change in behaviour of request.getRequestURI() is dictated by Servlet specification. The new behaviour (exposing the path parameters as is) is the correct behaviour. It is already mentioned above (comment 1) and have been discussed several times on our mailing lists. A request to clarify Servlet specification is [1]. The behaviour of getRequestURI is essentially clear: it is documented to return original un-decoded request URI, that is on the first line of HTTP request. [2] It is behaviour of other related methods that needs to be clarified in [1]. [1] https://java.net/jira/browse/SERVLET_SPEC-18 [2] http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpServletRequest.html#getRequestURI%28%29 3. This change was backported from Tomcat 7, where it was a part of a different fix that involved refactoring of path parameter handling. The change to getRequestURI() is a side effect of that refactoring. 4. Original proposal for this fix is r1005192 (2010-10-06) This proposal was discussed in "Re: r1005192" thread on dev@ list. After several minor improvements (r1035976) it became the change committed in r1149220. Discussion thread "Re: r1005192": http://tomcat.markmail.org/thread/i3m4amzrueafgvyv 5. Original commit that changed path parameter handling in Tomcat 7 is r944920 (2010-05-16, fix for bug 49299) with minor follow-up fixes such as r946584 and r1035973. In Tomcat 7 this change is part of Tomcat 7.0.0, so it is not listed in changelog. 6. This change in getRequestURI() behaviour has caused regression in FORM authentication: Bug 53584 - Forms authentication without cookies requires double submission in 6.0.33 The FORM authentication issue was fixed in 6.0.36, 7.0.30. (r1377878 in Tomcat 6, r1370537 + r1372390 in Tomcat 7)
I updated Tomcat 6 changelog in r1692377