HTTP Upgrade Handshake

## An HTTP request that is meant to stop being one A WebSocket connection does not begin with a client dialling a port of its own. It begins with **one ordinary HTTP/1.1 request**, sent to a normal web endpoint, asking the server to stop speaking HTTP on this connection and speak the WebSocket protocol instead. RFC 6455 calls this the **opening handshake**, and in its HTTP/1.1 form it happens exactly once per connection. If the server agrees, the request is never answered in the usual sense. There is no response body, no `Content-Length` to read, and nothing more to parse as HTTP: the blank line that terminates the response header block is the last HTTP byte on that connection, and every byte after it belongs to the WebSocket protocol. Reusing HTTP this way buys three things that matter in practice: - the request travels to the same ports and through the same request path as any other web traffic (`ws:` defaults to port 80, `wss:` to port 443); - it carries a mandatory `Host` field, so name-based virtual hosting works exactly as it does for pages; - the request line still names **an ordinary path**, so one host can expose many distinct WebSocket endpoints and route them the way it routes anything else. ## What the client MUST send 1. **The method `GET`**, on **HTTP/1.1 or higher**. No other method opens a socket in this form. 2. **`Host`** — the authority being addressed, as on any HTTP/1.1 request. 3. **`Upgrade: websocket`** — the protocol the client wants to switch to. The token is matched case-insensitively. 4. **A `Connection` field containing the token `Upgrade`** — this is what marks the `Upgrade` field as hop-by-hop, meaning it applies to this connection and not end to end. 5. **`Sec-WebSocket-Key`** — base64 text whose decoded form is **16 bytes**, chosen randomly and **freshly for every connection**. 6. **`Sec-WebSocket-Version: 13`** — the protocol version the client speaks. Optional fields may also ride along — `Origin`, `Sec-WebSocket-Protocol`, `Sec-WebSocket-Extensions` — but what they negotiate and what a negotiated value then means are separate subjects and none of them is required to open a socket. ## The response that ends the HTTP conversation | Element | Sent by | What it does | |---|---|---| | `101 Switching Protocols` | server | The status line that accepts the switch. Not `200`, not `204`. | | `Upgrade: websocket` | server | Names the protocol now in force on this connection. | | `Connection: Upgrade` | server | Confirms the switch applies to this connection. | | `Sec-WebSocket-Accept` | server | A digest derived from the client's `Sec-WebSocket-Key`, proving the peer implements this handshake. | | `Sec-WebSocket-Key` | client | The per-connection random nonce the digest is computed from. | | `Sec-WebSocket-Version` | client | The version the client speaks; the server refuses if it cannot. | Note the direction carefully, because it reverses easily under pressure: **the client sends the key, the server answers with the accept digest.** Never the other way round. ## After the blank line Once the client has validated the 101, the HTTP layer is finished with this connection. The bytes flowing in both directions from that point are WebSocket frames, whose bit layout, opcodes and length encoding are a separate subject; HTTP's message-framing rules no longer apply, and neither side is obliged to send anything at all. The connection then simply lives until one side closes it. This is also why the handshake is worth knowing precisely: it is the **only** moment in a socket's life when ordinary HTTP tooling, routing and diagnostics apply. Everything a candidate can say about the connection afterwards depends on having got this exchange right. ## What candidates get wrong - Describing the client as opening a raw connection and "then doing WebSocket", with no HTTP request in the story at all. - Answering `200 OK` as the success status. A `200` on an upgrade request means the request reached something that did not switch protocols, so no socket exists. - Treating the 101 as a normal response with a body to read. - Calling `Sec-WebSocket-Key` a credential the server checks to decide who may connect. It authorises nobody. - Believing a WebSocket URL cannot carry a path, and therefore that a host serves exactly one socket endpoint.