https://bz.apache.org/bugzilla/show_bug.cgi?id=61360
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |INVALID
Status|NEW |RESOLVED
OS| |All
--- Comment #1 from Mark Thomas <ma...@apache.org> ---
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.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
