----- Original Message ----- From: Phillip Morelock <[EMAIL PROTECTED]> > > 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.
To be perfectly honest I don't know, although I would have thought the IE's and Netscapes would adhere to the spec, especially as far as I remember Netscape were instrumental in introducing cookies. It's be relatively easily to check, but I don't have the time... > > fillup > > > On 5/28/02 9:02 PM, "James Williamson" <[EMAIL PROTECTED]> wrote: > > > > > ----- Original Message ----- > > From: Phillip Morelock <[EMAIL PROTECTED]> > > > > > >> 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" <[EMAIL PROTECTED]> wrote: > >> > >>> > >>> Thanks. Are all appservers required to behave this way or is this a > > Tomcat > >>> feature? > >>> > >>> > >>> -----Original Message----- > >>> From: Phillip Morelock [mailto:[EMAIL PROTECTED]] > >>> 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" <[EMAIL PROTECTED]> > > 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:[EMAIL PROTECTED]> > >>>> For additional commands, e-mail: > >>> <mailto:[EMAIL PROTECTED]> > >>>> > >>> > >>> > >>> -- > >>> To unsubscribe, e-mail: > >>> <mailto:[EMAIL PROTECTED]> > >>> For additional commands, e-mail: > >>> <mailto:[EMAIL PROTECTED]> > >>> > >>> -- > >>> To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > >>> For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > >>> > >> > >> > >> -- > >> To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > >> For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > >> > > > > > > -- > > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
