On Thu, 26 Jun 2003, David Keyes wrote:
> Date: Thu, 26 Jun 2003 08:59:46 -0400 > From: David Keyes <[EMAIL PROTECTED]> > To: Tomcat Users List <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Subject: RE: Cookie handling in IE6 and session handling of tomcat 4.1.24 > > IN GENERAL: > > For any two domains, A and B, if B is a subdomain of A (e.g., B.A), and > if two different J2EE app servers are hosting those domains, the > following will be true, assuming that the two appservers create session > cookies that are identical except for the domain (note that a cookie > consists of: name, domain, path, expiration): > > * If a user, running Internet Explorer, uses J2EE apps running on both > domains, causing a session to be established on both domains > simultaneously, the client accessing the application running in domain B > will not be able to access a session established in domain B. > > This is due to the fact that IE orders cookies from least-specific to > most-specific WITH RESPECT TO DOMAIN in an HTTP request. ANY app server > that looks for the FIRST cookie named JSESSIONID will be susceptible to > this problem. > > EXAMPLE: > > In our case, tomcat was serving up JSPs on "x.com", causing a J2EE > servlet session to be created when that page was loaded. Immediately > after hitting x.com, "w.x.com" was being loaded, which also caused a > session to be created. Both sessions were being identified by cookies > set in the client browser. The cookies both had an ID of JSESSIONID, > with an identical path. The only difference between the cookies was the > domain (one was "x.com", and the other was "w.x.com"). When interacting > with the app on w.x.com, each request included an HTTP header specifying > client-side cookies. In that header, the JSESSIONID created by x.com > was ordered BEFORE the JSESSIONID created by w.x.com. The appserver on > domain w.x.com was consequently attempting to find the session that had > been created on x.com, and since it could not, was creating a new > session with each request. > You probably want to address this as a bug report against Tomcat: http://nagoya.apache.org/bugzilla/ However, I can't see a lot of motivation to make Tomcat disobey the specs just because IE does. The real issue is that the incoming cookies only have names and values; there is no extra information with which to disambiguate them. Changing the current "take the first one" policy woud break Tomcat for all users on all browsers when you have context paths nested (instead of or in addition to domains), so it is not a general purpose solution. But it's an issue for the Tomcat developers to hash out. I'm not an active one any more (although I try to keep an eye on things there). > Dave Keyes Craig > > -----Original Message----- > From: Suraj Berwal [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 25, 2003 11:00 AM > To: Tomcat Users List" > Subject: Cookie handling in IE6 and session handling of tomcat 4.1.24 > > > dear tim, > i am facing a similar problem with my clients on IE6.0 regarding the session > handling using tomcat 4.1.24. Actually the data is getting swapped for users there. > can you please elaborate on the info you have posted about cookie problem in IE and > how it can affect the session handling in tomcat. i have a singlw webapp and the > tomcat is running on Standalone mode. > > re, > suraj berwal > > > > > >Do you have other webapps? I thought I recall at one time, some version of IE > >did send cookies in the correct order. This can hurt session handling in tomcat. > > >-Tim > > >Billy Ng wrote: > >> Hi folks; > >> > >> I have a customer complains the IE 6 sp1 times out the tomcat session way before > >> the tomcat default session time out >>settings. I tried to reproduce it but I > >> can't. Have anybody experienced this? > >> > >> Billy Ng > >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
