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:05:58 GMT
Jon Stevens wrote:

> is some wierdness in tomcat 3.2bx...this is what *appears* to be
> happening...i haven't looked at the code though (sorry, i don't have time
> right now)...
> in a single request:
>     i'm sending a cookie with an invalid jsessionid
>     i'm sending GET data with a valid jsessionid
>     the GET jsessionid is being ignored.
> i think that if there are multiple jsessionid's sent in a single request
> then they should all be considered. what does the servlet spec say about
> this?

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:


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

> -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