The change in [1] has broken existing behaviour in some applications. Consider the following situation: - An application is context path /application - The application has a servlet mapped to /* - An authentication valve intercepts requests to /application and returns (via a RequestDispatcher.forward()) a login page that POSTs back to the original path. An HTTP session is used to track the progress of the login process. - The application is accessed with Google Chrome with the URI http://server/application
What happens is: - During the redirection to the login page, Tomcat returns a JSESSONID cookie for the path /application/ - The login page then submits a POST to /application - Chrome (15.0 dev channel) and Internet Explorer (8.0) do not send the JSESSIONID cookie with the POST request - (In this particular app, an amusing loop results due to some session timeout handling) What's going on under the hood: - Tomcat (Mapper.internalMapWrapper Rule #2) is considering that there is a mapping for /application (the /*) - Tomcat is then setting a cookie for a /application/ This seems wrong - we're considering a path as being part of a context, but establishing a session that will not include that path (for some browsers at least). This notably makes Cookie based session tracking inconsistent with URL rewriting. Firefox (5.0) seems to sort this out and send the /application/ cookie on the /application requests. [2] made this behaviour configurable, but still defaulted it to the new behaviour of appending slashes. Questions I have: 1) Is what's described above the desired behaviour (that a path mapped to a web application might not be included in the web application session) 2) Should this change in behaviour have been made the default in Tomcat 7? 3) ... or are Chrome/IE or Firefox broken? tim ------------------ [1] https://svn.apache.org/viewvc?view=revision&revision=1100992 [2] http://svn.apache.org/viewvc?view=revision&revision=1101069 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
