On 18 December 2015 20:21:12 GMT+00:00, Jason Rivard <jriv...@gmail.com> wrote: >I'm not sure if I'm posting this in the right place, but I thought I >would >start here. It seems that changes to tomcat 8.0.29-30 partially >described >in the following bug break my application, and probably others: > >https://bz.apache.org/bugzilla/show_bug.cgi?id=58660 > >And here is my test application: > >https://github.com/jrivard/tomcat-root-redir-test > >Behaviors seen: > >The issue is that in 8.0.28, a request to the application context >"/context" would result in a redirect to "/context/". This handling >was >handed in a way that was invisible to the application code. > >In 8.0.29, this request is processed and the application generates a >response. > >In 8.0.30, this request is processed by the application, but generates >a >302 to "/context/" > >8.0.29-30 both break my test application in similar but distinct ways. >The >issue is that the application processes the initial request in a >filter, >modifies the session object, and then issues a redirect to itself. >Because >the JSESSION cookie path is set to "/context/" and not "/context", the >session seen on the subsequent handling of the redirect does not have >access to the same session object as on the first request. In a real >application that depends on similar behavior this breaks the >application in >significant ways. > >Another way to think of this is that it shouldn't be possible for the >application to access an HttpSession that doesn't match the browser's >session cookie. As of 8.0.30 this implied contract is broken because >on >the initial request to the "/context" url, application code has access >to >an effectively bogus HttpSession instance. > >I understand this can be worked around by setting context parameters >('mapperContextRootRedirectEnabled' for example), but it seems to me >the >default behavior shouldn't break existing apps - unless there is a >significant security reason - which I don't think is the case here. >Perhaps this new behavior could be reverted in 8.x and prior, and only >adopted in 9.x. > >If I've posted this in the wrong place, or if I should open a bug, >please >advise.
You can use sessionCookiePathUsesTrailingSlash on the Context to fix the session problem but be aware of the security risks if you have contexts with common prefixes. We might need to rethink the defaults of these inter-related Context options to get a set that it self-consistent and secure. Mark
