101 Switching Protocols
Interim response confirming the server is switching application protocols in response to an Upgrade header from the client.
Defined in RFC 9110 §15.2.2
What 101 means
HTTP 101 Switching Protocols is the server's acknowledgment of a client request to change the communication protocol on the same underlying TCP connection. The client signals this desire with an Upgrade header, commonly paired with Connection: Upgrade, naming the target protocol such as websocket or h2c. If the server is willing and able to speak that protocol, it responds 101, and from that point on both sides stop speaking HTTP and start exchanging frames or messages defined by the new protocol entirely.
The single most common use in production is the WebSocket handshake: a browser opens what looks like a normal GET request carrying Upgrade: websocket, Connection: Upgrade, and a Sec-WebSocket-Key, and the server replies 101 with a computed Sec-WebSocket-Accept value. Once that exchange completes, the connection is no longer HTTP at all, it is a raw bidirectional WebSocket stream, and any HTTP-aware middleware or logging in front of the server needs explicit support for the upgrade or it will break the handshake.
101 only ever appears over HTTP/1.1 connections, since HTTP/2 and HTTP/3 multiplex many logical streams over one connection and cannot hand the whole transport over to a different protocol; HTTP/2 instead defines h2c upgrade rules that are largely obsolete in practice, and WebSocket over HTTP/2 uses the separate CONNECT-based extended connect mechanism. Proxies, CDNs and load balancers must be configured to pass Upgrade and Connection headers through untouched, or the switch never completes and clients fall back to polling.
Common causes
- The client sent Connection: Upgrade and Upgrade: websocket (or another protocol name) alongside a normal HTTP/1.1 request.
- The server supports the requested protocol and has validated any handshake fields, such as Sec-WebSocket-Key.
- A load balancer or reverse proxy in front of the app is configured to pass Upgrade requests through instead of terminating them.
- An application is negotiating a plaintext HTTP/2 upgrade (h2c) on an older client that cannot start with HTTP/2 directly.
How to fix a 101
If you are the client (browser user or API caller)
- Send the Upgrade and Connection: Upgrade headers exactly as the target protocol's spec requires, including any handshake key.
- After receiving 101, immediately stop parsing the stream as HTTP and hand it off to the new protocol's client implementation.
- If the upgrade is rejected or silently ignored, check whether an intermediate proxy is stripping the Upgrade header and route around it.
If you run the server
- Confirm the requested protocol is supported before returning 101; fall back to a normal final status if it is not.
- Configure reverse proxies, load balancers, and CDNs to forward Upgrade and Connection headers and keep the TCP connection open after the switch.
- Compute and return any required handshake response value correctly, such as Sec-WebSocket-Accept for WebSocket.
- Set generous read and idle timeouts on upgraded connections so long-lived WebSocket sessions are not dropped by default HTTP timeouts.
Example
GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=Try it live
Our free status responder returns a real HTTP 101 you can point tests, monitors or a browser at.
GET https://mcp.httpstatus.com/status/101