On Tue, 22 May 2001, Marc Saegesser wrote:
> The code in Tomcat 3.2.x that encodeURL() uses to add the ;JSESSIONID=
> string to the URL makes several tests in order to prevent encoding a session
> ID onto a URL that doesn't belong the the current web application. One of
> these tests compares the URL scheme (HTTP, HTTPS) for the current request
> and the URL to be encoded and does not encode the session Id if the schemes
> are different.
>
> I have to admit that I'm not convinced that this is correct. The
> specification onlys says that if the URL does not need to be encoded
> encodeURL() returns the original string. There certainly isn't any reason
> to encode a session ID into an external URL, but I think the URL scheme test
> is a little too much.
>
> This isn't something that can be changed for 3.2.2 because it runs too high
> of a risk of breaking existing applications that depend on this behavior.
> It could be changed for 3.2.3 (if such a release ever comes about) and I'd
> be interested to see how 3.3 and 4.0 handle this situation.
>
In Tomcat 4.0, it's currently the same rule as 3.2.2 - the scheme, server
name, port number, and context path have to match in order for encodeURL()
or encodeRedirectURL() to actually include the session ID, which means
that sessions will *not* carry over when using URL rewriting.
Interestingly, though, they will carry over if you're using cookies (and
your browser sends cookies correctly when it is redirected - I had heard
some versions of Netscape had problems with this). In effect, cookies are
forwarded based on comparing host name and context path only. I'm going
to ask for some spec clarification, but this seems like the appropriate
behavior for URL rewriting as well (at least in servlet 2.3).
Craig
