- Client sends requested session ID to server
- Server returns assigned session ID to client (this may or may not be the same as the requested ID)
- Connection is upgraded to Websocket
The assigned session ID should be established as context for the WS session, rather than sent on top of the established WS.
An ideal flow may be:
- Client attaches session ID to the HTTP request as header or in query string
- Server decides on assigned ID and attaches it to the HTTP 1.1 101 Switching Protocols response as a header
- Client acknowledges and WS is established.
Key characteristics are that:
- The client can request an ID
- From the moment the WS is established, both the client and server are aware of the assigned session ID
I understand this approach cannot work due to header limitations with websockets, but maybe something like this:
- Client includes session ID to the HTTP request in query string (
- Server either sends the 101 response to upgrade the connection OR 302 redirects the client to a URL including the assigned session ID, which then follows with a 101.
- The client can introspect the assigned session ID with
I tried hacking this together, but receive:
WebSocket connection to 'ws://localhost:3000/ws?session=123' failed: Error during WebSocket handshake: Unexpected response code: 302
I would appreciate any guidance on architecting a flow that achieves my desired characteristics.