> -----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. Jeff
