tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <Craig.McClana...@eng.sun.com>
Subject Re: jsessionid wierdness
Date Sun, 15 Oct 2000 23:25:38 GMT
Jon Stevens wrote:

> on 10/15/2000 4:05 PM, "Craig R. McClanahan" <Craig.McClanahan@eng.sun.com>
> wrote:
>
> > It doesn't say anything directly -- but there is enough justification IMHO for
> > Tomcat's policy of considering the cookie as more important (Tomcat 4.0 does
> > this as well):
> >
> > * The API implies that the container must choose one and only
> > one "authoritative" requested session id:
> >
> > HttpServletRequest.getRequestedSessionId()
> >
> > along with the methods to tell you where the requested session
> > ID was found (it could be both places)
> >
> > * Cookies are described as "the most used session tracking
> > mechanism" which must be supported
> >
> > * URL rewriting is described as a "fallback mechanism" for
> > when the client does not support cookies.
> >
> > But there is no guarantee every servlet container will utilize this reasoning.
> >
> > For maximum portability, then, you'd best make sure that you send the same
> > session ID back if it comes in as both a path parameter and a cookie.  Among
> > other things, this implies that, if you're going to switch sessions, you need
> > to do so before the servlet generating your response calls
> > response.encodeURL() or response.encodeRewriteURL().
>
> Craig, you didn't really answer my email. :-)
>

Well, I tried, but it's definitely not the answer you want to hear :-).  See more
below.

>
> If two come in, then I think they should both be checked regardless of which
> is more important or not.
>
> You can certainly say that the Cookie based one is checked first, which
> would solve your importance statement, but I think that doesn't mean that
> the second one should just be ignored if the first one is invalid.
>
> Of course HttpServletRequest.getRequestedSessionId() would return the one
> sessionid that was "known" to the container as being valid.
>

It would certainly be possible to make Tomcat behave the way you describe.  But,
since it's not spec'd specifically (in the absence of asking for a clarification
from the spec lead that there is an "unwritten" policy here -- which you might want
to initiate), I would submit that all of the following approaches to your scenario
(invalid session id in the cookie, valid session id in the request URL) are legal
per the servlet spec:

* Listen to the cookie only

* Listen to the request URL path parameter only

* Consider both and take whichever is valid (which
  begs the question of what to do if they are *both*
  valid :-)

* Consider that the app is providing inconsistent
  information and take neither (well, this probably
  isn't defensible, but sheesh :-).

Given that the behavior isn't spec'd, I would tend to take measures in my app to
avoid situations where behavior is not guaranteed to be portable.

>
> thanks,
>
> -jon
>

Craig

====================
See you at ApacheCon Europe <http://www.apachecon.com>!
Session VS01 (23-Oct 13h00-17h00):  Sun Technical Briefing
Session T06  (24-Oct 14h00-15h00):  Migrating Apache JServ
                                    Applications to Tomcat



Mime
View raw message