tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Suraj Berwal" <suraj.ber...@bhartitelesoft.com>
Subject Re: Cookie handling in IE6 and session handling of tomcat 4.1.24
Date Thu, 26 Jun 2003 14:41:27 GMT
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]




Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message