-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Jeff,
On 9/11/15 10:09 AM, Jeffrey Janner wrote: >> -----Original Message----- From: Christopher Schultz >> [mailto:ch...@christopherschultz.net] Sent: Thursday, September >> 10, 2015 2:24 PM To: Tomcat Users List <users@tomcat.apache.org> >> Subject: Re: Multiple JSESSIONID cookies being presented. >> >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >> >> Jeffrey, >> >> On 9/10/15 12:26 PM, Jeffrey Janner wrote: >>> Thanks for all the help guys. I think I've sussed out what is >>> going on here. Now just have to get the Dev guys to address >>> it. >>> >>> After spending a good bit of time clearing and watching >>> cookies and access logs, both with and without a favicon.ico >>> file, I found that the doubling was happening only if the file >>> was missing. I checked the error.jsp file and it does have >>> session=true set, and if the icon file is missing, the >>> error.jsp is definitely being sent. >>> >>> So it looks like the possible solutions are: 1) provide a >>> favicon.ico file. >> >> This fixes the symptom, not the problem. You'll get the same >> problem with clients who request /apple-touch-icon.png, >> /robots.txt, or just about any other file that ends up resulting >> in a 404. This could be something from within the application >> itself, and will (apparently) cause mass confusion. >> >>> 2) remove the session=true setting from the error page. >> >> This is the right answer. Do you really need the session in >> error.jsp? >> >>> 3) somehow not send the error.jsp when a sub-link (image, >>> script, etc.) results in a 404. >>> >>> 4) Have the login page of APP2 provide it's own icon <link> >>> directive (it doesn't currently have one.) >> >>> Any other options? >> >> If you absolutely need access to the session in your error.jsp >> file, you can do this: >> >> <?jsp session="false" ?> <% HttpSession session = >> request.getSession(false); >> >> ... %> >> >> This will prevent sessions from being created when there isn't >> already a session. You'll have to check the code for error.jsp to >> make sure that no code uses the session before checking it for >> null -- because session="true" guarantees that the "session" >> reference will be non-null. >> >> That will allow you to use session information in error.jsp if a >> session already exists, but not create a superfluous session when >> one does not (yet) exist. >> > Thanks for the above Chris. I passed the information on to someone > who can get it implemented. > >> Back to Tomcat's session management: Tomcat *can* handle this >> situation properly: it will try all JSESSIONID cookies it gets to >> find a valid one in the current web application. So, multiple >> JSESSIONID cookies won't confuse Tomcat. Some other component >> must be mis-understanding the session identifier in some way. >> >> - -chris > > Yes, I don't think it's bothering Tomcat at all. We've never > experienced a problem with direct-to-tomcat configurations, and > we've had this setup for years. We recently implemented an HaProxy > front-end using stick-tables and think it's potentially confusing > HaProxy. But I can't swear to that, because I did find a problem > with how jvmRoute was being applied, resulting in both servers > providing the same value, so that could have been the underlying > problem all along. However, the session on error is a basics issue > that needs to be resolved. Thanks again. I think we are done > here. I think I missed that part about switching to HAProxy. If you are using sticky sessions, HAProxy needs to know that session X was replaced by session Y. That ought to happen because Tomcat will be sending Set-Cookie response headers, and HAProxy ought to pick-up on it, but it's possible something is getting confused during the scuffle. - -chris -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJV8z/cAAoJEBzwKT+lPKRYLnkP/icNKczwo6lNH+mCd4mMnTUn 9Lsgz+sRDxjE4d8+ccKlv1cYi+ava0zEAQWgKgeWcxaBGO9NvUyTiXy6CIQKMBNW dNYQBreU2aVDlFAuLHPzCGSjSRpt9RFC15tCrAqCFKXcQF8S3pkYtzEWgwXVB1mH 5GRpkqyMj+4HDPDUVQXxu5NBUPuu7p2JZroMtXeo0Na1P6AXpmer0/KOqR0EYDwD oGYMKtRWcZcXeYpUJNi1PlWYLl753N1tJL5j1rwXUJKOG25mekhf3tX9V4EjALOp LvA1/GSD5OQMEBfzBXEIjT5dmRJMwi1mkPGwzFtS9FN0dVCdhjofCIdnPLTCGXy8 R9dHIcql3EEcq2zulW4Ai6e7rm57CkwEPzuwT1p+pjVkH0fj7zaZJhjcZaKzFoRc fkwA/9Q3P6l/f6xkjeI07kXtY8MqdHLWK/nIISs1F4vbJfKQ5Ki0Aw1jJwgzn/1O ITFWRk5WW5IJsXkoItFUBMbkqsNNi319rg64XJFS9Dt8oKRaw+ENwKPOZVSCZ05n l9nxtj8kiqGNaigG7WcAfQSsx8JUbRvpt44yTI6zl7zLav+Dcig5DKeHpztfvxDb aumO17zH2KwUh2zfdl7zFr6mc7AYYkaQb/1lpM4ehvsvXIStj45J00tzvkKLrYwp M6N24e0Oia9aBzmLoiVc =egHr -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
