tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jon Stevens <>
Subject Re: jsessionid wierdness
Date Sun, 15 Oct 2000 23:12:08 GMT
on 10/15/2000 4:05 PM, "Craig R. McClanahan" <>

> 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. :-)

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.



--    |      | |       |

View raw message