RE: Problem in Transferring session between http and https on Netscape
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.
RE: Problem in Transferring session between http and https on Netscape
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
- Original Message - From: Deepak Raina [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
Thanks for your reply but thing is we are not using URL rewriting.We are using cookies to maintain the session(default). And we are using cookies for other things like remeber password.That thinh is working fine in NETSCAPE. Only problem comes when we try to transfer from http to https or vice versa. I think other people are using it.Like in hotmail when a user login his data is sent by https but after that it's transferred back to http. So is it due to the combination of both NETSCAPE and TOMCAT?Becaz the same thing is working in IE. regards, Deepak Raina INTIQUA India B-65 Okhla Industrial Area - I New Delhi 110 020 Main: +91-11-681 2931 Fax: +91-11-681-0023 [EMAIL PROTECTED] http://www.intiqua.com -Original Message- From: Marc Saegesser [SMTP:[EMAIL PROTECTED]] Sent: Tuesday, May 22, 2001 6:48 PM To: [EMAIL PROTECTED] Subject: RE: Problem in Transferring session between http and https on Netscape 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. 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.
