tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject RE: Cookie handling in IE6 and session handling of tomcat 4.1.24
Date Thu, 26 Jun 2003 18:28:42 GMT


On Thu, 26 Jun 2003, David Keyes wrote:

> Date: Thu, 26 Jun 2003 08:59:46 -0400
> From: David Keyes <david.keyes@flashline.com>
> To: Tomcat Users List <tomcat-user@jakarta.apache.org>
> Cc: craigmcc@apache.org
> 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:suraj.berwal@bhartitelesoft.com]
> 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: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


Mime
View raw message