-----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 -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJV8H9WAAoJEBzwKT+lPKRYUrUP/jFofb1kyXtipLisOXrDRKRi dXgapMR+XsBMUNBqQOCbwM1YRn2IV9+pF2oJaLtN/R36rweoYMywvbqc6LWG+MuL oOu8Qe7t5RRXVbOdvP5hYPTNiVDNGPYSmPHg5gbGsPNfhUWqMNutWbQBxZwjX+kH Q0P71bgk2Nf4Ch0wqjQImCsO+oQH2BeHUOCC7FLYsRa8r8nS8Ml0MXmvQl57yZzB cUm/V4Z1ygh8QxvB2ZmIber2KFVx4gJyZh6usTnpkb0lm7x1H0PUylpklyYSTJKv thR3DSgVjLe582I8/2/rIjpGhqqP/TUAv9INh7WprzLGTb4wQQRKkPYAwy/9vxhI 4+PDs6qTalS9iti8GdA5MIg6CuK55Gu26rvlC+FNSsYQMMMzedySTri1tJQgCkJd JQL97eoouNFd3K06EuCyUWIoOfGqCNNoYpDYaxN/IeBwbefSR8mUctWsWKDdX6MJ p7/I3saRu3na8oLR4nnZz8a/I/oIQWwvJebHMN3UFuSgBLxIwgurE6LHZ8tSP2YP D/QYKSnY+KoGb7tPR4O0FTxr7EULUFtVgWPCy6WePi1jkVxqmKPD3rIU+TtPzwLb QDiI4W4O3lL97F1iZNcjNGnbDgpOcJdhJjORFQl/KEX8r6D9fN0h0LjgSuuEJnr7 JrNmcEq8wsZxM1VgxtRn =ZL2V -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
