101 Switching Protocols: How Protocol Upgrades Work
How the Protocol Upgrade Works
The client initiates an upgrade by sending the Upgrade header in an HTTP/1.1 request, along with a list of protocols it supports (e.g., Upgrade: websocket). If the server agrees, it responds with status 101 and includes the chosen protocol in the Upgrade response header. After that, the connection switches to that protocol.
Example: WebSocket Handshake
| Step | Direction | HTTP Message |
|---|---|---|
| 1 | Client → Server | GET /chat HTTP/1.1 |
| 2 | Server → Client | HTTP/1.1 101 Switching Protocols |
| 3 | ↔ | WebSocket protocol active — binary or text frames exchanged |
Common Use Cases
- WebSocket – real‑time bidirectional communication (chats, live feeds, gaming).
- HTTP/2 or HTTP/3 – negotiated via ALPN during TLS handshake; 101 is also used for prior‑knowledge upgrades.
- WebDAV – switching to a different protocol version.
Important Constraints
The 101 response is only sent after the server has received the entire request headers. It is an informational (1xx) response, so the client should expect the connection to be handed over to the upgraded protocol immediately after this response.
Frequently Asked Questions
Is 101 Switching Protocols required for WebSocket?
Yes. The WebSocket protocol specification mandates that the server respond with 101 to complete the handshake. Without it, the connection cannot upgrade.
What if the server does not support the requested protocol?
If the server doesn't support the requested upgrade, it should ignore the Upgrade header and respond with a normal 2xx or 4xx status, continuing in HTTP/1.1 mode.
Can I use 101 for custom protocols?
Technically yes, but both client and server must agree on the protocol name and its implementation. Custom upgrades are uncommon outside proprietary systems.