James Mitchell wrote: >What exactly is your question? > >Err....well did you answer your own question? > >If I am understanding what you are saying: > ><taking-a-poke-at-it> > >If struts appends the sessionid in case the client doesn't accept cookies, >why wasn't I prompted about cookies that were never set? > > >Am I way off here? > >JM > >>-----Original Message----- >>From: jfc100 [mailto:[EMAIL PROTECTED]] >>Sent: Tuesday, April 30, 2002 12:58 PM >>To: Struts Users Mailing List >>Subject: Re: ideal method to set the sessionid in struts? >> >> >>Tero P Paananen wrote: >> >>>>What is happening here? >>>> >>>Your app server sets the session id cookie. >>> >>> -TPP >>> >>>-- >>>To unsubscribe, e-mail: >>> >><mailto:[EMAIL PROTECTED]> >> >>>For additional commands, e-mail: >>> >><mailto:[EMAIL PROTECTED]> >> >>> >>So does this mean that I never have to set cookies? >> >>(I'm using jboss.) >> >> >> >>-- >>To unsubscribe, e-mail: >><mailto:[EMAIL PROTECTED]> >>For additional commands, e-mail: >><mailto:[EMAIL PROTECTED]> >> >> > > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > It looks as though the container automatically performs the basic level of session tracking and the 2.3 Servlet spec suggests this too. i.e.
> SRV.7.1.1 Cookies > Session tracking through HTTP cookies is the most used session > tracking mechanism and is required to be supported by all servlet > containers. The container sends a cookie to the client. The client > will then return the cookie on each subsequent request to the server, > unambiguously associating the request with a session. The name of the > session tracking cookie must be JSESSIONID. ... and ... > SRV.7.1.3 URL Rewriting > URL rewriting is the lowest common denominator of session tracking. > When a client will not accept a cookie, URL rewriting may be used by > the server as the basis for session tracking. URL rewriting involves > adding data, a session id, to the URL path that is interpreted by the > container to associate the request with a session. The session id must > be encoded as a path parameter in the URL string. The name of the > parameter must be jsessionid. Here is an example of a URL containing > encoded path information: > http://www.myserver.com/catalog/index.html;jsessionid=1234 SRV.7.1.4 > Session Integrity Web containers must be able to support the HTTP > session while servicing HTTP requests from clients that do not support > the use of cookies. To fulfil this requirement, web containers > commonly support the URL rewriting mechanism. So if this is supported in tomcat/catalina(and hell, it is the reference imp!) then I think I can assume that calling 'request.getSession()' explicitly will always return an existing session. Is that correct? Joe -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
