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 contex t
Date Wed, 29 May 2002 04:26:05 GMT
> Set-Cookie: JSESSIONID=D4F42E4F346F947DDB409C0B8F6BDA19;Path=/
> 
> However, telnetting to a context such as http://www.mydomain.com/context/
> and I'll get this sent back:
> 
> Set-Cookie: JSESSIONID=D128650F08DCF7B371FCC29E79E87AD7;Path=/context

Of course, but do you know of a browser that actually respects the path
statement in this way?  It was my impression that there are always
collisions with an identically named cookie (JSESSIONID) but this could
easily be outdated knowledge on my part.  I have seen this before and just
worked around it, but it was some time ago.

fillup


On 5/28/02 9:02 PM, "James Williamson" <james@nameonthe.net> wrote:

> 
> ----- Original Message -----
> From: Phillip Morelock <subscriptions@phillipmorelock.com>
> 
> 
>> 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.
>> 
> 
> This is why the cookie rfc introduces the path element in the cookie header,
> i.e. telnetting to Tomcat and sending a request for a context bound to the
> root of the domain, i.e. http://www.mydomain.com/ will give me this in
> my headers sent back:
> 
> Set-Cookie: JSESSIONID=D4F42E4F346F947DDB409C0B8F6BDA19;Path=/
> 
> However, telnetting to a context such as http://www.mydomain.com/context/
> and I'll get this sent back:
> 
> Set-Cookie: JSESSIONID=D128650F08DCF7B371FCC29E79E87AD7;Path=/context
> 
>> 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."
> 
> If browsers respect cookies and paths they shouldn't do this (see above), I
> can
> see an problem if you have a context mounted at / and one at /context
> although
> I'm not totally sure which cookie(s) the browser will send back, an
> intelligent
> browser would either send both or the cookie more specific to the path
> requested.
> 
> Regards,
> 
> James Williamson
> www.nameonthe.net
> UK Tomcat Hosting
> 
>> 
>> 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>
>> 
> 
> 
> --
> 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