Thanks Craig, that confirms what I have previously read on the subject. It
also concerns me a little bit. There are legitimate times when the user may
want to open two different sessions (browsers) of a web application. Using
cookies to maintain the session there would be no way to identify the
separate client instances. You would have to reinvent your own session
management mechanism based on some other id value.
Using URL rewriting you could accomplish this. I'm surprised that the spec
hasn't made it a forceable alternative by now. Especially with the misplaced
concern over cookies the past couple years.
jim
> -----Original Message-----
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> Sent: Monday, March 12, 2001 7:41 PM
> To: [EMAIL PROTECTED]
> Subject: Re: The use of '..' in relative path includes in JSPs
>
>
>
>
> On Mon, 12 Mar 2001, James Cook wrote:
>
> > Sorry to keep repeating this, but I don't think I phrased it properly.
> >
> > Is there a technique where the session id is included in the
> URL even if the
> > client browser supports cookies? Basically, I *never* want to
> use cookies to
> > manage sessions, and I *always* want the session id encoded on the URLs.
> >
>
> The only way I can think of to do this is to configure your servlet
> container to not use cookies for session management, if it has such an
> option. Tomcat versions greater than 3.1 can do this, but I don't know
> about any other containers in particular.
>
> Absent that approach, you could create a modified version of the
> <html:link> tag that forcibly included the session ID (in other words, it
> did the processing that response.encodeURL() usually does), but the cookie
> would still be included in the response as well, and the container will
> probably pay attention to the cookie, and not the session id from the URL,
> in subsequent requests.
>
> > thanks,
> > jim
> >
>
> Craig
>
>
