WebSocket Handshake and HTTP Upgrade Process — Internals

The WebSocket handshake is deliberately designed to look like an ordinary HTTP request so it passes through firewalls and proxies that only understand HTTP. The protocol's RFC uses a specific mechanism to prove the server understands WebSocket, not just HTTP.

The handshake sequence:

• The client sends a standard GET request with Upgrade: websocket and a random Base64-encoded Sec-WebSocket-Key
• The server proves it understands WebSocket by responding with 101 Switching Protocols and a Sec-WebSocket-Accept header — a SHA-1 hash of the client's key concatenated with a fixed magic GUID from RFC 6455; any other status code means you're still on HTTP
• After the switch, both sides communicate through compact binary frames with a 2–14 byte header containing the opcode, payload length, and masking information

The masking requirement:

• All client-to-server frames must be XORed with a random 4-byte key — this is not encryption; it prevents intermediary proxies from mistaking WebSocket payloads for cacheable HTTP responses, which would enable cache-poisoning attacks
• This is an RFC 6455 requirement and non-compliance causes most well-behaved servers to close the connection

The Spring Boot hook:

• HandshakeInterceptor.beforeHandshake() runs before the 101 response is sent — your last chance to validate JWT tokens and reject bad connections before committing server memory to a long-lived socket
• Once the upgrade completes, HTTP headers are gone; validate everything at handshake time because STOMP-level auth on the CONNECT frame is a secondary layer

I recommend implementing JWT validation in the HandshakeInterceptor as the primary auth layer, not relying solely on STOMP-level checks that run after server resources are already allocated.