Hi,
> > We always have the problem, that we might get multiple session ids (from
> > the URL, from _multple_ cookies).
>
> You should not be getting multiple session id cookies for different
> webapps unless (a) the context paths overlap, or (b) your client is not
> following the rules of the specs. See my comments on Bug 10419 for more
> info on how situation (a) is dealt with.
ok, sounds good.
Considering that the client sends the right cookie for that context first,
there is the only problem, that we still can get two session-ids in
a request
o from the URL
o from the cookie.
Currently, a cookie overrides a session-id that has been gotten from the
URL unconditionally.
The whole point here is: if that session id from the cookie is
invalid because:
a) The session in the cookie is expired or has been invalidated
b) The session in the cookie comes from a different application
context because for _this_ application context there is no
cookie, thus the other cookie is placed first
we don't get a HttpSession in the application since it tries to look up
it with the wrong ID.
If users have cookies enabled all the time, this is probably not the case.
Others might be a bit more picky when to allow cookies and in that case
the 'override anything requested in the URL' scheme might not be a good
idea. Dealing with both possible session ids and give preference to the
one that is currently valid in that context should be the goal.
-hen
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
