tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <ma...@apache.org>
Subject Re: / on end of context paths breaking existing apps
Date Sun, 21 Aug 2011 21:57:31 GMT
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message