https://bz.apache.org/bugzilla/show_bug.cgi?id=58765
Bug ID: 58765
Summary: Default behavior change in tomcat 8.0.29-30 context
root redirect process
Product: Tomcat 8
Version: 8.0.30
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Catalina
Assignee: dev@tomcat.apache.org
Reporter: jriv...@gmail.com
Changes to tomcat 8.0.29-30 break applications that modify attributes on the
HttpSession object on the initial root context url request, and possibly other
places. This behavior change is partially described in bug 58660.
Behaviors seen:
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 application in similar but distinct ways. The cause 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 have created a test application that shows the different behaviors:
https://github.com/jrivard/tomcat-root-redir-test
The behavior can be reverted to the 8.0.28 style by setting the context
parameter mapperContextRootRedirectEnabled=true.
I recommend the default of this setting - or some other equivalent - be changed
to false.
This issue can also be corrected by changing the context parameter
sessionCookiePathUsesTrailingSlash=false, however this has a potentially
negative security impact so I don't think this default should be changed.
In any case, the default behavior for this execution path should not be
changing on point releases. My understanding is there is a similar issue in
the 7.x and 9.x branch but I haven't tested them.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
