Problem in Transferring session between http and https on Netscap e

[Deepak Raina <De...@intiqua.com>]

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.

Re: Problem in Transferring session between http and https on Netscape

[Casper Gjerris <ca...@mdb.ku.dk>]

----- Original Message -----
From: "Deepak Raina" <De...@intiqua.com>

> > 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.

I believe that this is a question for tomcat-user@jakarta.apache.org

but since I am not 100% sure, here is what I have know:
Netscape 4.x has a bug so cookies will only be transfered if you use
standard ports (80 and 443)

http://host/foo
https://host/foo

will work just fine, but

http://host:8080/foo
https://host/foo

will not work.

Some people claims that even

http://host:80/foo
https://host/foo

will not work, because the port number is included in the URL.

Let me know if this is correct.

Casper Gjerris

RE: Problem in Transferring session between http and https on Netscape

["Craig R. McClanahan" <cr...@apache.org>]

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

RE: Problem in Transferring session between http and https on Netscape

[Marc Saegesser <ma...@apropos.com>]

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:Deepak.Raina@intiqua.com]
> Sent: Tuesday, May 22, 2001 6:35 AM
> To: tomcat-dev@jakarta.apache.org
> 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.
>