----- 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]>
