Gurmeet, I'm pretty sure this is because the page you were looking at was cached on your browser. When you clicked refresh, the server returned an updated copy. Because of Tomcat's behavior with https -> http, you then lost your session.
This has happened to me a ton of times. As developers, we're constantly looking at pages multiple times for testing. One of the best things to do is to create a jsp tag/code that prevents caching in both the document's html and prevent caching at the request level (2 different methods...the request level is the correct way, but MS IE requires both methods). This way, while testing, you never see a cached page. When its time for deployment, you can remove the tags/code that prevents caching if you want to allow it to your users. Les Gurmeet writes: > Hi, > > It might drive me crazy. > > But I just noticed one thing. > > I have a JSP with a bean in session scope ---it swtches to https ----does > something ---- switches back to http --- in this jsp in http I call a method > on the bean which was there in session , it returns me the value as if it > sustained the session, but when I refresh the page it behaves otherwise. > > I have not applied the patch yet. > > Any clue. why? > > Gurmeet > > -----Original Message----- > From: Manuel Mall [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, March 27, 2002 7:09 AM > To: 'Tomcat Users List' > Subject: RE: Session lost when switching from https to http in Tomcat 4 > > > Anders, > > thanks, I will try your patch and hope that the Tomcat developer community > will take your suggestion to make this behaviour configurable on board. > > Manuel > > -----Original Message----- > From: Anders Rundgren [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, 26 March 2002 18:38 > To: [EMAIL PROTECTED]; Tomcat Users List > Cc: Peter Tornberg > Subject: Re: Session lost when switching from https to http in Tomcat 4 > > > You are right Manuel, > > Tomcat 4.0.2 using SSL unfortunately always sets a &Secure flag > on JSESSIONIDs, which do not (depending on browser) allow > you to do this https->http switch. > > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6983 > > A Macintosh using IE 5 cannot even obtain a _standard_ SSL jsession due to > this. > > This is why I have requested this behavior to become an option. > > The option would actually disable a cookie-RFC compliant feature, > but so what, if you cannot get things to work? > > cheers, > Anders > > ----- Original Message ----- > From: "Manuel Mall" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, March 26, 2002 11:17 > Subject: Session lost when switching from https to http in Tomcat 4 > > > Has the session semantic changed between Tomcat 3 and Tomcat 4? > > We have a servlet/JSP application in which users establish their servlet > session using https but conduct the rest of their interactions using http. > This works fine under Apache 1.3.22 with Tomcat 3.2.1 connecting using > ajp12. > > After upgrading to Tomcat 4.0.3 now using ajp13 the session appears not to > be preserved between https and http, ie. after switching back to http the > request.getSession(false) call returns null. > > This seems to indicate that the session tracking mechanism has changed > between Tomcat 3 and Tomcat 4. Can anyone shed light on this for me? Is this > expected? Is there a workaround/configuration/setting in Tomcat 4 I might > have missed? > > Thanks > > Manuel > > -- > To unsubscribe: <mailto:[EMAIL PROTECTED]> > For additional commands: <mailto:[EMAIL PROTECTED]> > Troubles with the list: <mailto:[EMAIL PROTECTED]> > > > > -- > To unsubscribe: <mailto:[EMAIL PROTECTED]> > For additional commands: <mailto:[EMAIL PROTECTED]> > Troubles with the list: <mailto:[EMAIL PROTECTED]> > > -- > To unsubscribe: <mailto:[EMAIL PROTECTED]> > For additional commands: <mailto:[EMAIL PROTECTED]> > Troubles with the list: <mailto:[EMAIL PROTECTED]> > > > -- > To unsubscribe: <mailto:[EMAIL PROTECTED]> > For additional commands: <mailto:[EMAIL PROTECTED]> > Troubles with the list: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe: <mailto:[EMAIL PROTECTED]> For additional commands: <mailto:[EMAIL PROTECTED]> Troubles with the list: <mailto:[EMAIL PROTECTED]>
