tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
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" <>
> 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

> 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


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

View raw message