Marc Saegesser wrote:
>
> I'm reviewing Bugzilla bugs in preparation of the Tomcat 3.2.2 release.
> Bugzilla 160 has been open since Tomcat 3.1 and it looks like its real and
> that it violates the Servlet 2.2 spec.
>
> I want to make sure I am correctly interpretting the spec before I dig too
> deep. I'll send a similar message to the servlet api mailing list.
>
> 1) HttpServletRequest.getRequestedSessionId() should return the session
> that arrived with the request. This might not match the session id returned
> by HttpServletRequest.getSession()because the session might have been
> invalidated or timed out, etc. So far so good. What isn't clear (at least
> from reading the code) is should calling HttpServletRequest.getSession()
> modify the requested session id. I think that it shouldn't but the code in
> RequestImpl.java updates the requested session id. A quick look at the
> Tomcat 3.3 version appears to work as I expected it to.
Your interpretation of the spec is the same as mine: Calling getSession()
should not modify the *requested* session ID. In other words, you need to
keep track of both the requested and the actual session ID to implement
these methods.
> 2) A related question, HttpServletRequest.isRequestedSessionIdValid() is
> implemented as follows:
>
> HttpSession session = (HttpSession)request.getSession(false);
> return (session != null);
>
> If this method is called *before* the invoking servlet calls
> getSession(true) then it will correctly determine if the *requested* session
> id was valid. After that it will always return true. This seems wrong
> because specification clearly states this method determines if the requested
> session id was valid. Tomcat 3.3 appears to suffer from this problem.
Again, my interpretation is the same as yours. You should test if the
requested session is the same as the actual session instead.
Hans
--
Hans Bergsten hans@gefionsoftware.com
Gefion Software http://www.gefionsoftware.com
Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com