> -----Original Message----- > From: Christopher Schultz [mailto:ch...@christopherschultz.net] > Sent: Wednesday, September 09, 2015 1:50 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/9/15 12:08 PM, Jeffrey Janner wrote: > >> -----Original Message----- From: Caldarale, Charles R > >> [mailto:chuck.caldar...@unisys.com] Sent: Tuesday, September 08, > >> 2015 4:58 PM To: Tomcat Users List <users@tomcat.apache.org> > >> Subject: RE: Multiple JSESSIONID cookies being presented. > >> > >>> From: Jose María Zaragoza [mailto:demablo...@gmail.com] > >>> Subject: Re: Multiple JSESSIONID cookies being presented. > >> > >>>> Thanks for the clarification of what's supposed to happen on > >> receipt, Jose. > >>>> However, I am describing what happens on first contact from > >>>> the > >> client to the server. > >>>> The browser sends https://hostname/APP2, and Tomcat returns: > >>>> JSESSIONID=XXXX, path=/ and JSESSIONID=YYYY, > >>>> path=/APP2/ > >> > >>> Indeed, it doesn't make sense for me to return different id ( > >>> XXXX , YYYY ) if you are accesing to only one context (/APP2) > >> > >>> Are you sure that your webapp deployed in /APP2 is not accesing > >>> to resources ( session-aware resources as JSP, servlet, .. .I > >>> mean) stored in ROOT context ? > >> > >> As I think someone previously mentioned, the client (browser) may > >> well be sending an unsolicited request to the default webapp, > >> such as when trying to retrieve favicon.ico. You might want to > >> run Fiddler or Wireshark on the client to see exactly what's > >> being sent to the server. > >> > > > > And there's no way to keep a browser from asking for the > > favicon.ico file from the root. We don't have one, so I would > > expect a 404 is sent, which looking at the access log file is what > > happens. However, is this the issue? I tested this doing a manual > > https://hostname/favicon.ico and see that we also return our root > > app's error page. We also seem to be doing that for the > > auto-generated request, judging by the bytes returned value, even > > though it won't get displayed. And I bet that the error page is > > setting the session cookie for some reason. Does that sound > > reasonable? Is my solution just providing a favicon.ico file? > > Can you make sure that all cookies have been cleared from the test > client and then explain exactly when Tomcat sends the Set-Cookie headers > ? > > When we had this problem, it was usually because the client had old > funky session ids in its cookie jar and the solution was to blow them > all away and start-over fresh. (Then fix our software so it wouldn't > happen anymore.) > > - -chris 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. 2) remove the session=true setting from the error page. 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? Jeff --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
