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.
> -----Original Message-----
> From: Deepak Raina [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, May 22, 2001 6:35 AM
> To: [EMAIL PROTECTED]
> Subject: Problem in Transferring session between http and https on
> Netscape
>
>
>
> I had asked this problem yesterday also.Can somebody please tell me the
> solution???
> > I'm working on a website where some pages are to be kept in
> https and some
> > on http.But when we transfer
> > from https to http, session is not transferred in Netscape.It's working
> > fine in
> > IE.We are using tomcat. Is there anything i should do with
> tomcat so that
> > it transfers the session in Netscape or i have to do something in the
> > settings of the Netscape?
> >
> regards,
> deepak.
>
>
>
> ____________________________________________________
> INTIQUA India
> Intelligent solutions, Quality Execution
> ____________________________________________________
>
> Note: The information and data contained in this message (and attachments)
> may be privileged and confidential and protected from disclosure to any
> party or parties apart from the intended recipient. If the reader of this
> message is not the intended recipient, or an employee or agent responsible
> for delivering this message to the intended recipient, you are hereby
> notified that any dissemination, distribution or copying of this
> communication is strictly prohibited. If you have received this
> communication in error, please notify us immediately by replying to the
> message and deleting it from your computer.
>
