Created attachment 35190 [details] A simple webapp to reproduce the problem Steps to reproduce the problem: 1. Setup tomcat to serve https and http 2. deploy attached directory (see README.txt inside) 3. Open Chrome or FF, request the https resource, afterwards request the http resource. Watch the tomcat console, httpSession is reported to be null! 4. If you first request http, then https and again http, it works fine (then http has http-session not null). What is the expected behavior? The httpSession object in case of http should be not null. But every reload of the http case, the http session is null. Only if you close and open the browser, then navigate to http, it is ok (not null). Does this feature work correctly in other browsers? - It works correctly in MSIE 11. - In Firefox same problem as in Chrome. I reported this as a bug for Chrome (#749833) but Chrome developer say it's likely to be a Tomcat problem.
This is as a result of user agent behaviour. Tomcat marks the session cookie for sessions created under https as secure. This ensures that user agents do not send session IDs for secure sessions over http. In the http->https case - The first request creates a session and sets a non-secure session cookie - The browser sends this session cookie with the ws request - The second request continues to use the session cookie because sending a non-secure cookie over https is allowed - The wss request uses the non-secure session cookie for the same reason In the https->http case - The first request creates a session and sets a secure session cookie - The browser sends this session cookie with the wss request (since secure cookies can be sent with https requests) - The second request continues does not use the session cookie because sending a secure cookie over http is not allowed. Tomcat creates a new session and sends the user agent a non-secure cookie for that session - The user agent ignores this cookie (I'm guessing so that it doesn't over-write the secure one in case of a switch back to https) - The ws request is also sent without a session cookie. Hence the WebSocket handshake does not see a session.
Thank you very much for the explanation!