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.
