With Jenkins 1.504 under Tomcat 7 and anonymous browsing disabled in Jenkins, a user can get stuck, unable to login into Jenkins if he's using either Chrome or IE and attempts to access Jenkins using a URL in the form of http://hostname/webapp, without the trailing slash.

Under these circumstances, the following happens:
1.
User accesses http://hostname/jenkins
Jenkins returns 403 with a meta refresh/JS redirect to "/jenkins/login?from=%2Fjenkins"
Tomcat sets a JSESSIONID for the path /jenkins/

2.
Browser accesses http://hostname/jenkins/login?from=%2Fjenkins, sending the new JSESSIONID cookie
Jenkins displays the login page
User submits form, browser POSTs to http://hostname/jenkins/j_acegi_security_check (still sending the same JSESSIONID)
Jenkins returns a 302 with Location: http://hostname/jenkins

3.
Browser accesses http://hostname/jenkins
Chrome and IE DO NOT send the JSESSIONID cookie, because /jenkins does not match /jenkins/ (Firefox still sends the cookie regardless in this case)
Jenkins returns 403 with a meta refresh/JS redirect to "/jenkins/login?from=%2Fjenkins"
Tomcat sets a JSESSIONID for the path /jenkins/, overwriting the old cookie and trashing the authenticated session client-size

4.
Browser accesses http://hostname/jenkins/login?from=%2Fjenkins once more, sending the new JSESSIONID, which corresponds to a new, unauthenticated session, and the user is back to step 2, entering a loop.

This can be avoided if the user tries to access http://hostname/jenkins/ at first, but it still isn't perfect, since the workflow then becomes:
1. User accesses http://hostname/jenkins/, 403 with redirect to /jenkins/login?from=%2Fjenkins/ and cookie set to path /jenkins/
2. Browser GETs http://hostname/jenkins/login?from=%2Fjenkins/
3. Browser POSTs to http://hostname/jenkins/j_acegi_security_check, 302 with Location: http://hostname/jenkins/
4. Browser GETs http://hostname/jenkins/, sends cookie, user is logged in.

However, if at this point, the user tries going to http://hostname/jenkins manually, the browser won't send the cookie (path won't match) and a 403 will be returned together with a new cookie, which will overwrite the user's cookie in the browser and log him out.

Because of this, just making sure that Jenkins doesn't redirect the user to /jenkins isn't enough, since one can still get logged out by manually accessing /jenkins afterwards. Therefore, it seems to me that making /jenkins always issue a "302 Found" redirect to /jenkins/, even before processing any authentication data (and only then either issuing 403 or continuing with displaying content) would be the cleanest way of solve this problem.

The currently available workaround for Tomcat 7 that fixes this issue is to set sessionCookiePathUsesTrailingSlash to false in the <Context> element of Tomcat's configuration (http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Common_Attributes). This makes Tomcat issue session ID cookies with "/jenkins" rather than "/jenkins/". However, requiring this solution at the container level seems dirty to me.