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]
