Netscape has (in the past, at least, and it sounds like the current version is the same) viewed the following as different servers: http://somehost.com/ https://somehow.com/
These are equivalent to: http://somehost.com:80/ https://somehost.com:443/ It actually seems like a reasonable assumption to me, considering they very well could be totally different server instances running on the same hardware. The result is that cookies sent from somehost.com:80 are not sent with requests to somehost.com:443. This includes the session cookie, so when you switch you get a new session. The common solution is to explicitly set the cookie domain of all cookies sent by the server to simply 'somehost.com'. By explicitly setting the cookie domain in this way, cookies set by the server on one port of somehost.com will be sent to servers on other ports. Specifically, if the client connects to somehost.com:80 and gets a session cookie with the domain 'somehost.com' (as opposed to 'somehost.com:80'), the browser will include that cookie in requests to somehost.com:443 (since it matches the 'somehost.com' cookie domain, where it would not match 'somehost.com:80'). The details of doing this depend on your server, but a search for "cookie domain" should help locate the details of setting the value. Steve (sslext author) describes this issue in his article: http://www.javaworld.com/javaworld/jw-02-2002/jw-0215-ssl-p3.html It is kind of a pain to set and maintain the cookie domain as you deploy on different servers for development, QA, production, etc. If you have a server on qa.mycompany.net (your QA server) and the cookie domain is set to mycompany.com (your production machine), you will get a new session with every request, since the browser will never include the session cookie in any of its requests (because the server name and cookie domian don't match). I would suspect that the browser would just reject the cookie outright, since the cookie domain is clearly not a match for the server that sent it in the first place. I haven't tried it, but I wonder if the session ID could be included as part of the URL for all links/redirects/etc that jump from HTTP to HTTPS or back. It would be a pain to take the care to rewrite all such "jumper" URLs in this way, but that might be an easier maintenance burden to bear than setting the cookie domain in the server config. If it works, this might be a cool new feature for sslext (I'll forward this message to Steve to see what he thinks). Again, I haven't tried this but it seems like it might work. -Max ----- Original Message ----- From: "Dung Nguyen Huu" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Tuesday, March 11, 2003 3:56 AM Subject: RE: switching from non SSL to SSL in struts.. > Hello all, > > I've used sslExt for our web application (for struts 1.0) and now I am > facing problem. > In out app, there is a need to put some small data into HttpSession for > reuse later, the problem is while switching from Http -> Https or vice > versa, the data put into HttpSession are lost if web client is Netscape > (6.1), It seems that Netscape use different session for HTTP and HTTPs...!!! > Meanwhile, our app works well with I.E. > > Any idea are welcome and appreciated ? > > > > > -----Original Message----- > > From: James [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, March 11, 2003 10:39 AM > > To: [EMAIL PROTECTED] > > Subject: Re: switching from non SSL to SSL in struts.. > > > > > > i found it as you replied.. > > > > thanks anyway.. > > > > > > > > "Guido" <[EMAIL PROTECTED]> wrote in message > > news:[EMAIL PROTECTED] > > > Oh no! This topic again!! :P > > > > > > Take a look at sslext (sslext.sourceforge.net) or search > > this mail list > > > for it. > > > > > > hth, > > > Guido. > > > > > > James wrote: > > > > I've got my SSL connector configured in tomcat.. what i > > want to know is > > what > > > > do i need to do to change to secure page from non secure pages in > > struts... > > > > > > > > an example of this would be going from 'shopping cart' to > > 'checkout'.. > > is > > > > this a configuration issue? > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
