-----------------------------
Please read the FAQ!
<http://java.apache.org/faq/>
-----------------------------
Jean-Luc Rochat wrote:
> "Craig R. McClanahan" wrote:
> > jon * wrote:
> >
> > > -----------------------------
> > > Please read the FAQ!
> > > <http://java.apache.org/faq/>
> > > -----------------------------
> > >
> > > > Thanks for your help, but another list reader recognized my problem as one
> > > > which is defined here: http://bugs.apache.org/index/full/4382 .
> > >
> > > actually it is more than that. what i said is true and is the way it will be
> > > as far as i can tell (correct me if i'm wrong please). sessions will not be
> > > valid across zones. if you need that functionality, abstract the sessioning
> > > from your application.
> > >
> > > -jon
> > >
> >
> > Jon is correct ... the 2.1 and 2.2 servlet API specs confirm that sessions will
> > not be valid across servlet contexts (i.e. zones in Apache JServ terminology).
> > However, the original bug report is still a real issue -- you should be able to
> > have multiple sessions active (one per zone), and this does not work in AJ 1.0
> > because of the way we use a single cookie name.
> >
> > The "correct" thing to do is to set the session management cookie's path to be
> > the "context path" of this context, but this concept was only introduced in the
> > 2.1 API, and Apache JServ does not insist that there is such a thing.
> >
> > The "simple" thing to do would be to make the name of the session management
> > cookie a per-zone configuration parameter, so that different cookies can be
> > used for each zone. Suitable care will need to be taken to ensure that this
> > doesn't mess up the load balancing code, which (if I remember right) also
> > counts on knowing what the name of the session management cookie is. I'm still
> > in the swamped stage on an implementation project -- can someone else take a
> > crack at this?
> >
> > Craig McClanahan
> if I remember correctly, I proposed monthes ago a patch for this
> question (April 1999: "RFC : 1 sessionId per zone" from Jean-Luc
> Rochat), and we discussed on the dev list about it.
> (and this was not breaking the LB stuff).
> James Duncan Davidson had a "-1" on this idea :
> I have all opinions here (including yours Craig) on the subject.
> <quote>
> > This idea makes sense to me, and it's consistent with the direction of the
> > 2.1 servlet API as well (the scope of a session is a servlet context, which
> > implies that it's legal to have more than one active session on the same
> > host -- and the only way to do this is to have different cookie names for
> > each zone/context).
>
> Actually not really necessary... In the upcoming JSDK impl, all
> application level sessions (those within a context) are keyed in on the
> same cookie. This means that there's only one "SESSION_ID" cookie per
> host but all the HttpSessions for a host are managed independently even
> though they share id.
>
> .duncan
> </quote>
>
> Jean-Luc
>
James's comments are consistent with my thoughts on the "correct" approach (in the
notes above). The reason that the 2.1 JSDK gets away with this is that they can
make the assumption that a ServletContext (i.e. a zone) has a "context path" at the
front of the URL, and they can set the cookie's "path" to this value. The unique
key for a cookie is actually NAME + DOMAIN + PATH, not just NAME + DOMAIN. Thus,
the following two cookies are distinct (even though they have the same name):
Name=JServSessionId, Domain=mycompany.com, Path=/zone1, Value={sessionkey1}
Name=JServSessionId, Domain=mycompany.com, Path=/zone2, Value={sessionkey2}
The problem is that, AFAIK, Apache JServ 1.0 does not require you to have a common
"context path" prefix for the servlets in a particular zone -- you can glue together
any combination of prefixes you want. Thus, we cannot rely on being able to use the
path to share the same cookie name.
The workaround of using different cookie names is just that -- a workaround based on
the fact that the Apache JServ design predated the 2.1 servlet API spec, and it's
introduction (implicit in 2.1, explicit in 2.2) of the concept of a "context
path".. IMHO we should make this workaround functional in the load balancing code,
and just use it for now.
Craig
PS: By the way, there's talk on the servlet API developer's list, for some future
API version, of specifying both the name of the cookie being used for session
management, and the mechanism for encoding session IDs in a URL (we use a query
parameter, most engines append some punctuation mark and the session ID). The
reason to do this would be to help proxy servers maintain session identity
correctly, by being able to pass the correct values on when they are relevant. The
point of this is that we will definitely want to go back to a single cookie name
approach in the future -- but I don't think that is practical for 1.0.
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
