Re: Cookie handling in IE6 and session handling of tomcat 4.1.24
Dear Tim, thanks for your reply. well I have checked the genearted java code for my jsp page. I see no instance variables being declared there only local varaiables. the variables we have defined are also being declared locally inside the doservice() method. however i would like to point out that this problem is occuring only in the internal network of the client. whenever we access that site from our end through the web no such problem is encountered. can you please give some more inputs on any other aspect I might have missed out. thanks regards, suraj b. From: Tim Funk Subject: Re: Cookie handling in IE6 and session handling of tomcat 4.1.24 Date: Wed, 25 Jun 2003 08:45:35 -0700 The scenario I described was different. There is some version of IE that does not send cookies of the smae name in the correct order. This messes up session handling. Your issue is different since there are not seperate webapps but users seeing each other session data. There have been many discussions about tomcat handing out duplicate session ids and tomcat swapping user sessions. For the most part - i never recalled any real issue with tomcat on any of these complaints. It usually turned out being a coding issue - such as a concurrency issue because a servlet or JSP used class instance variables instead of local variables. -Tim Suraj Berwal wrote: 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
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. Dave Keyes -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]
Re: Cookie handling in IE6 and session handling of tomcat 4.1.24
Hi All, I have resolved the problem today. The problem was that the cache in the proxy at the client side was not getting refreshed with each request whereas it was on the browser. So the proxy was at first instance serving the pages from the cache itself. But on refreshing the page the user was able to see the original content and not always. The problem was resolved by expiring the cache on the proxy also. Strange thing is that the html pages had the Expires meta-tag enabled but that does not work with cache. David, thanks for your exhaustive info but we don't have two domains here. we only have one domain x.com and one application running on that domain. Any other inputs are welcome. Regards, Suraj Berwal. - 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. Dave Keyes -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]
RE: Cookie handling in IE6 and session handling of tomcat 4.1.24
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]
RE: Cookie handling in IE6 and session handling of tomcat 4.1.24
Unfortunately, IE does NOT disobey the spec. The spec is ambiguous about what to do in this scenario, and Microsoft (big surprise) just chose to do things differently than everyone else. The spec (RFC 2109) says in section 4.3.4: If multiple cookies satisfy the criteria above, they are ordered in the Cookie header such that those with more specific Path attributes precede those with less specific. *** Ordering with respect to other attributes (e.g., Domain) is unspecified.*** I added the emphasis. I don't see a good solution to the problem, other than removing the mandate in the servlet spec that says JSESSIONID must be used to identify the cookie... Dave -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] Sent: Thursday, June 26, 2003 2:29 PM To: David Keyes Cc: Tomcat Users List Subject: RE: Cookie handling in IE6 and session handling of tomcat 4.1.24 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]
Re: Cookie handling in IE6 and session handling of tomcat 4.1.24
The scenario I described was different. There is some version of IE that does not send cookies of the smae name in the correct order. This messes up session handling. Your issue is different since there are not seperate webapps but users seeing each other session data. There have been many discussions about tomcat handing out duplicate session ids and tomcat swapping user sessions. For the most part - i never recalled any real issue with tomcat on any of these complaints. It usually turned out being a coding issue - such as a concurrency issue because a servlet or JSP used class instance variables instead of local variables. -Tim Suraj Berwal wrote: 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
