All active windows starting from the same session should be sharing the same cookies. As I said, we have no problem in every version of IE unless you have installed update Q813951. Opening a new window should not cause the session cookie to disappear.
Originally posted by Frank Carver:
I've seen plenty of applications which baldly assumed that all active browser windows share cookies, history, favourites etc.
Wouldn't that be either a 301 or 302?
Originally posted by Mike Curwen:
Using sendRedirect actually sends one of those 500-level error codes ( i forget the exact one ) that means "the page you're looking for is gone, check this one instead".
> -----Original Message-----
From: Craig R. McClanahan [mailto:email@example.com]
Sent: Thursday, June 26, 2003 1: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 <firstname.lastname@example.org>
> To: Tomcat Users List <email@example.com>
> Cc: firstname.lastname@example.org
> Subject: RE: Cookie handling in IE6 and session handling of tomcat
> 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.
> 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:
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
I've been selected to go to the moon! All thanks to this tiny ad:
free, earth-friendly heat - a kickstarter for putting coin in your pocket while saving the earthhttps://coderanch.com/t/751654/free-earth-friendly-heat-kickstarter