Tomcat 3.2.2 [was: RE: Spec Compliance: getRequestedSessionId(), ...]

[Marc Saegesser <ma...@apropos.com>]

After some further investigation into session ids and url rewritting I've
found more places in the Tomcat 3.2 code that are using the requested
session id as the active session id.  I'm tracking down and fixes these now.

These code changes are beyond what I'm willing to accept, as a release
manager, during a beta release.  The release plan called for a single beta
cycle with the provision of additional betas if necessary.  Once these bugs
are resolved I will create a Tocmat 3.2.2 beta 2 release for evaluation.

> -----Original Message-----
> From: Marc Saegesser [mailto:marc.saegesser@apropos.com]
> Sent: Monday, March 05, 2001 6:45 PM
> To: tomcat-dev@jakarta.apache.org
> Subject: RE: Spec Compliance: getRequestedSessionId(), ...
>
>
> The Servlet 3.2 API spec (PFD) attempts to clarify this some, but I think
> muddles it even further with some truly odd wording.
>
> I'm going to fix this in 3.2.2 unless I hear something contrary from the
> serlvet-api folks.  Its kind of late in the game for code changes to 3.2.2
> but I really hate known spec failures.
>
> > -----Original Message-----
> > From: hans@servlets.net [mailto:hans@servlets.net]On Behalf Of Hans
> > Bergsten
> > Sent: Monday, March 05, 2001 6:32 PM
> > To: tomcat-dev@jakarta.apache.org
> > Subject: Re: Spec Compliance: getRequestedSessionId(), ...
> >
> >
> > 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
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, email: tomcat-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, email: tomcat-dev-help@jakarta.apache.org