You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Marc Saegesser <ma...@apropos.com> on 2001/03/06 00:46:47 UTC
Spec Compliance: getRequestedSessionId(), ...
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.
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.
Tomcat 3.2.2 [was: RE: Spec Compliance: getRequestedSessionId(), ...]
Posted by 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
RE: Spec Compliance: getRequestedSessionId(), ...
Posted by Marc Saegesser <ma...@apropos.com>.
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
Re: Spec Compliance: getRequestedSessionId(), ...
Posted by Hans Bergsten <ha...@gefionsoftware.com>.
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