On 21/08/2011 22:49, Tim Whittington wrote: > 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) Yes. The / is added for security reasons. Requests for /foobar should not see cookies set for the context with path /foo.
> 2) Should this change in behaviour have been made the default in Tomcat 7? I think so but I tend to give security related changes a higher priority than backwards compatibility. The community may disagree. > 3) ... or are Chrome/IE or Firefox broken? IE is arguable broken (add this to the list of stuff IE doesn't handle correctly for cookies). Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
