Return-Path: Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 96286 invoked from network); 6 Mar 2001 00:45:18 -0000 Received: from unknown (HELO mail.apropos.com) (198.63.198.2) by h31.sny.collab.net with SMTP; 6 Mar 2001 00:45:18 -0000 Received: from MSAEGESSERLPT (10.1.16.1 [10.1.16.1]) by mail.apropos.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id FYZJR88Z; Mon, 5 Mar 2001 18:44:15 -0600 From: "Marc Saegesser" To: Subject: RE: Spec Compliance: getRequestedSessionId(), ... Date: Mon, 5 Mar 2001 18:44:55 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: <3AA42FF7.9A14476E@gefionsoftware.com> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N 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