Larry,
I commited the changes to HttpServletResponseFacade that fix the problems
with determine when URLs should be rewritten and what session id to use. I
also beefed up the SessionExample servlet from the examples webapp to
display additional information and allow sessions to be invalidated. This
helped determine that the fixes did the right thing.
> -----Original Message-----
> From: Larry Isaacs [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, March 06, 2001 10:33 AM
> To: '[EMAIL PROTECTED]'
> Subject: RE: Tomcat 3.2.2 [was: RE: Spec Compliance:
> getRequestedSessionId(), ...]
>
>
> Hi Marc,
>
> Does it look like a few days to come up with these patches?
> If so, I would like to include any missing from Tomcat 3.3
> in Milestone 2.
>
> Thanks.
>
> > -----Original Message-----
> > From: Marc Saegesser [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, March 06, 2001 10:27 AM
> > To: [EMAIL PROTECTED]
> > Subject: Tomcat 3.2.2 [was: RE: Spec Compliance:
> > getRequestedSessionId(), ...]
> >
> >
> > 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:[EMAIL PROTECTED]]
> > > Sent: Monday, March 05, 2001 6:45 PM
> > > To: [EMAIL PROTECTED]
> > > 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
> > Behalf Of Hans
> > > > Bergsten
> > > > Sent: Monday, March 05, 2001 6:32 PM
> > > > To: [EMAIL PROTECTED]
> > > > 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 [EMAIL PROTECTED]
> > > > Gefion Software http://www.gefionsoftware.com
> > > > Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com
> > > >
> > > >
> > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, email: [EMAIL PROTECTED]
> > >
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, email: [EMAIL PROTECTED]
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, email: [EMAIL PROTECTED]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
