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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to