Yoav
Either you're wrong or Tomcat 5.0.x may be broken...
With cookies enabled you can transfer the session from a non-secure connection to a secure connection for the same domain/webapp. Tomcat does NOT generate a new (secure) session.
The problem is that TC 5.0.28 does not exhibit the same behaviour when cookies are disabled. In this case, Tomcat does in fact generate a new (secure) session.
So what we have here appears to be non-consistant behaviour from Tomcat based on client behaviour beyond the control of the web app developer... :(
And all because response.encodeRedirectURL(url) did not append the jsessionid to the URL when switching protocols. If encodeRedirectURL appended the session id, then you would have consistant behaviour from Tomcat.
Now it could be that using response.encodeRedirectURL(url) is not the correct way to pass the session from an http to https connection. And in fact the only way to guarantee that the non-secure session data is passed to the secure connection is using the following hack:
url = url + ";jsessionid=" + session.getId()
when cookies are disabled.
My personal preference is to create a new static method which takes the current request and the new request URL and generates a correctly rewritten URL (based on the fact that I want the non-secure session passed to the secure pages). And to use that whereever I have been using response.encodeRedirectURL(url) and response.encodeURL(url)
I still that Tomcat is broken/inconsistant on this point...
Any other thoughts or solutions, anyone?
John Sidney-Woollett
Yoav Shapira wrote:
> Hi,
> Not a bug. You can't share a session that way, whether using cookies > or URL-rewriting.
>
> Yoav Shapira http://www.yoavshapira.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
