tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phillip Morelock <subscripti...@phillipmorelock.com>
Subject Re: Cannot retrieve session after visiting a different servlet co ntex t
Date Tue, 28 May 2002 23:56:28 GMT
It's a "feature" of the Servlet specification if you will...actually it's
somewhat of an accident of nature, given the way browsers are specified to
work WRT cookies.

- Cookies are (in the world of Web browsers) inherently server-name based.
so if you get a cookie from "www.yahoo.com" you will send that cookie on
each subsequent request to "www.yahoo.com" -- and further, you will __only__
send it to "www.yahoo.com", or anything under that domain (meaning
"xxx.www.yahoo.com" also gets this cookie from you).  Also, if you get a
cookie from "yahoo.com" then you will send that cookie to ANY site with the
pattern *.yahoo.com.

- Contexts under the servlet specification are based on the first / after
the site name.  So "www.mysite.com/foobar" and "www.mysite.com/jimmy" are
two different applications, with two different hash tables for their session
objects.  They "can't" know about each other -- this is a security and
configuration feature -- see the servlet specification.

So -- do "all" appservers behave this way?  Yes and no.  I will tell you
that all appservers whose basis for distinguishing applications is like the
Servlet specification's -- based on top-level virtual path -- then, yes,
without some special hacking or customization, the app server will behave
this way (unless they specifically tell you otherwise, in other words).  So
it's not just a "Tomcat" thing.

You might consider instead of your current scheme to use virtual hosts.
Instead of "www.mysite.com/app1" and "www.mysite.com/app2" you could have
"app1.mysite.com" and "app2.mysite.com" as one way of working around this
"feature."

cheers
fillup


On 5/28/02 4:43 PM, "Ghanshyam Patel" <Ghanshyam.Patel@VITALPS.COM> wrote:

> 
> Thanks. Are all appservers required to behave this way or is this a Tomcat
> feature?
> 
> 
> -----Original Message-----
> From: Phillip Morelock [mailto:subscriptions@phillipmorelock.com]
> Sent: Tuesday, May 28, 2002 4:33 PM
> To: Tomcat Users List
> Subject: Re: Cannot retrieve session after visiting a different servlet
> contex t
> 
> 
> This is happening because browsers associate cookies with the name of the
> server, whereas Session ID's among tomcat contexts do not cross over.
> 
> Since the cookie / identifier for the session is something like JSESSIONID
> and is associated in the client browser with your server, this property gets
> overwritten when you visit the other context, because TC will not recognize
> your JSESSIONID as belonging to this context.  It will assume you have an
> expired session and generate a new one.  When you go back to the other
> context, then of course this happens again, because THAT context won't be
> expecting your new JSESSIONID.
> 
> fillup
> 
> 
> On 5/28/02 4:20 PM, "Ghanshyam Patel" <Ghanshyam.Patel@VITALPS.COM> wrote:
> 
>> 
>> I am using Tomcat 4.0.3 and have 2 servlet contexts running in the same
> JVM.
>> 
>> Session SA is created when I visit a page served by servlet context A.
>> Session SB is created when I visit a page served by servlet context B.
> Now,
>> when I revisit a page served by context A, a new session is created! I
> would
>> expect to find session SA instead of a new session. Is this normal? Why is
>> this happening?
>> 
>> Thanks
>> Ghanshyam
>> 
>> --
>> To unsubscribe, e-mail:
> <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
>> For additional commands, e-mail:
> <mailto:tomcat-user-help@jakarta.apache.org>
>> 
> 
> 
> --
> To unsubscribe, e-mail:
> <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:tomcat-user-help@jakarta.apache.org>
> 
> --
> To unsubscribe, e-mail:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:tomcat-user-help@jakarta.apache.org>
> 


--
To unsubscribe, e-mail:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-user-help@jakarta.apache.org>


Mime
View raw message