Non-smartphone cookie storage methods of Au (KDDI), HTTP and HTTPS are different:
Store the HTTPS domain name and end-to-end cookie
Store the HTTP Response site and GW response cookie
In this way, the session IDs of HTTPS and HTTP are inconsistent.
The session data stored in HTTPS cannot be found in HTTP;
Session data stored in HTTP cannot be found in HTTPS.
In applications, such as "no login", "No Exit", "sesssion data loss", and "no migration from shopping cart to checkout.
My solution is:
Add JSESSIONID to all URLs.
In that case, during page migration, whether http-> https, or https-> HTTP, the session ID will always be held in the URL,
Even if the cookie stored in HTTPS and HTTP are inconsistent, the session ID cannot be obtained from the cookie, and the session ID can still be obtained from the URL.
In this case, the session ID value should be consistent, that is, the data stored in the session is shared by HTTP and HTTPS.
This can be basically solved.
PS: In addition, when investigating this problem, I saw a blog post and comments, which seemed to solve a similar problem. You can refer to it.
Http://java-guru.iteye.com/blog/157897#bc520405
As mentioned in this blog, for enhanced security, cookies generated under the HTTPS protocol are not transmitted to the HTTP protocol starting from Tomcat 4.0.
That is, when the session ID is migrated from http to HTTP, it is not written into the cookie.
The solution of the blogger is to write the session ID in the filter to the cookie.
This approach may be better, especially in PCs and smart phones that generally use cookies. It is preferred not to display session IDs in URLs.