Unless somebody has come out with a new specification for cookie handling that I'm not aware of this information is incorrect. Browsers *should* carry cookies across http/https boundaries unless the cookie comes with a "Secure" attribute. If the "Secure" attribute is included the cookie should only be returned over secure connections (generally https). If the "Secure" attribute is not set for a cookie that cookie should be returned over both http and https connections matching the host name and path.
Early versions of IE broke the cookie specification and treated http as different from https, so that cookies originally sent under one type of connection were not recognized and sent back under the other type of connection. This was an error which they hopefully fixed in later versions (though I haven't checked). Netscape implemented the cookie handling as specified (not to surprising, since they wrote the original specification). See: http://wp.netscape.com/newsref/std/cookie_spec.html http://www.w3.org/Protocols/rfc2109/rfc2109 - Dennis Adrian Janssen wrote: >Web Browsers (IE andNN) do not cary sessions across http / https boundries. > >If you dump out the session id, which is a cookie sent by the browser with >every page request then you will see that it differes between the http and >https pages. This is for security reasons. > >Or to put it another way http://some.url is not in the same context as >https://some.url in fact it is as different as >http://someother.differenturl. > >The way to get around this, is once you move to https for eg the login page, >then stay in https for all subsequent pages (such as the home page) > >Cheers >Adrian > > > > > >>-----Original Message----- >>From: Chanel Tien [SMTP:[EMAIL PROTECTED]] >>Sent: 12 June 2002 09:23 >>To: [EMAIL PROTECTED] >>Subject: Problem with user http session >> >>Hi, >> >>I am having difficulty in solving a problem with user http session. >>In theory, the login submit servlet will create a session to store >>the newly logged in user information, and the redirected Home servlet >>should be able to read the user session information. This works, if >>the login servlet and the Home servlet both have the same root url >>(ie http://localhost:8080 ...). But it does not work, if from the Home >>servlet I redirect to the secure Login servlet (ie >>https://localhost:8443 ...). >>And the from the secure Login I redirect back to the normal Home >>servlet (ie http://localhost:8080/ingui/Home); in this case, the session >> >>does not contain the info I stored from the LoginSubmit servlet. >> >> >>Regards, >> >> >> >>-chanel >> >> ___________________________________________________________________________ To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff SERVLET-INTEREST". Archives: http://archives.java.sun.com/archives/servlet-interest.html Resources: http://java.sun.com/products/servlet/external-resources.html LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
