101 Switching Protocols
What is HTTP 101 Switching Protocols?
When your computer talks to a website, they usually use a language called HTTP. ...
Explain Like I’m 3
Two friends start talking in English, then one says ‘Let’s speak Spanish now!’ and they both switch to Spanish. That’s what computers do - they start talking one way, then switch to a different way!
Example: You and your friend start playing with blocks, then you say ‘Let’s play with trains instead!’ and you both switch to playing with trains.
Explain Like I’m 5
When your computer talks to a website, they usually use a language called HTTP. Sometimes, they need to switch to a different language that’s better for certain things, like having a real-time conversation. The website says ‘101 Switching Protocols’ which means ‘Okay, let’s start using that new language now!’ Then they both switch and keep talking in the new way.
Example: A chat app like a game chat needs to send messages instantly back and forth. First it connects normally, but then it says ‘Let’s switch to a faster way of talking’ and uses something called WebSocket so messages appear right away.
Jr. Developer
HTTP 101 Switching Protocols means the server is agreeing to upgrade the connection from HTTP to a different protocol that the client requested. This most commonly happens when establishing WebSocket connections for real-time communication. The client sends an Upgrade header requesting the switch, and if the server supports it, it responds with 101 and immediately starts using the new protocol. After this response, the connection is no longer using HTTP - it’s now using whatever protocol was agreed upon (usually WebSocket).
Example: A real-time chat application needs WebSocket for instant message delivery. The client initiates an HTTP request with Upgrade: websocket header. The server responds with 101 Switching Protocols, and from that point forward, the connection uses the WebSocket protocol for bidirectional communication.
Code Example
// Client-side WebSocket connectionconst socket = new WebSocket('ws://localhost:3000');// Browser automatically handles the HTTP -> WebSocket upgrade
socket.onopen = () => { console.log('Connected! Protocol switched to WebSocket'); socket.send('Hello server!');};
socket.onmessage = (event) => { console.log('Message from server:', event.data);};Crash Course
101 Switching Protocols is an informational response indicating the server accepts the client’s request to upgrade to a different protocol, specified in the client’s Upgrade header. The most common use case is upgrading HTTP connections to WebSocket for real-time, bidirectional communication. The handshake involves the client sending an HTTP request with Upgrade and Connection headers, and the server responding with 101 plus protocol-specific headers like Sec-WebSocket-Accept. After receiving 101, both client and server immediately switch to the new protocol - no more HTTP is exchanged on that connection. This enables persistent, low-latency connections essential for chat applications, live feeds, collaborative editing, gaming, and streaming.
Example: A collaborative document editor needs instant updates when users type. The client initiates with GET /socket HTTP/1.1 plus Upgrade: websocket and Connection: Upgrade headers. The server validates the request, responds with 101 Switching Protocols, and includes the WebSocket acceptance key. The connection immediately transitions to WebSocket mode, allowing real-time bidirectional data flow without HTTP overhead.
Code Example
// Server-side WebSocket upgrade handling (Node.js)const http = require('http');const WebSocket = require('ws');
const server = http.createServer();const wss = new WebSocket.Server({ server });
wss.on('connection', (ws, request) => { // Connection upgraded to WebSocket (101 was sent) console.log('Client connected via WebSocket');
ws.on('message', (message) => { console.log('Received:', message); ws.send(`Echo: ${message}`); });});
server.listen(3000);Deep Dive
The 101 Switching Protocols status code, defined in RFC 9110 Section 15.2.2, indicates the server understands and is willing to comply with the client’s request to switch application protocols on the current connection. This mechanism enables protocol upgrade without establishing a new connection, preserving the underlying TCP connection while changing the application-layer protocol. The upgrade is negotiated through the Upgrade header field (RFC 7230 Section 6.7), which can list one or more protocols in order of preference. The server must include an Upgrade header in the 101 response identifying the chosen protocol(s).
Technical Details
The WebSocket upgrade process, governed by RFC 6455, is the predominant use of 101 responses. The handshake requires specific headers: Upgrade: websocket, Connection: Upgrade, Sec-WebSocket-Key (client nonce), Sec-WebSocket-Version (typically 13). The server validates these, derives Sec-WebSocket-Accept by concatenating the client’s key with the magic GUID ‘258EAFA5-E914-47DA-95CA-C5AB0DC85B11’, SHA-1 hashing it, and base64 encoding the result. This proves the server understands WebSocket protocol.
Once 101 is sent, the connection semantics fundamentally change. The TCP connection remains, but HTTP message framing is replaced by the new protocol’s framing. For WebSocket, this means binary frames with opcode, payload length, masking key, and payload. Intermediate proxies must be aware of protocol upgrades - those that don’t understand the Upgrade header may break the connection or interfere with the upgraded protocol.
Security considerations include validating the Origin header to prevent unauthorized cross-origin WebSocket connections, enforcing same-origin policies where appropriate, and ensuring TLS is used (wss://) for sensitive data. The protocol switch is irreversible for that connection - there’s no mechanism to downgrade back to HTTP. HTTP/2 explicitly prohibits the Upgrade mechanism (RFC 7540 Section 3.2), using ALPN (Application-Layer Protocol Negotiation) during TLS handshake instead.
Other protocols that may use 101 include HTTP/2 over cleartext (h2c), though this is rare in production. The TLS-based HTTP/2 negotiation via ALPN is preferred. Some IoT protocols like MQTT can be layered over WebSocket connections initiated with 101 upgrades.
Code Example
// Manual WebSocket handshake implementation (educational)const crypto = require('crypto');const net = require('net');
const server = net.createServer((socket) => { socket.once('data', (data) => { const request = data.toString(); const keyMatch = request.match(/Sec-WebSocket-Key: (.+)/);
if (keyMatch) { const key = keyMatch[1].trim(); const MAGIC_STRING = '258EAFA5-E914-47DA-95CA-C5AB0DC85B11'; const acceptKey = crypto .createHash('sha1') .update(key + MAGIC_STRING) .digest('base64');
// Send 101 Switching Protocols response const response = [ 'HTTP/1.1 101 Switching Protocols', 'Upgrade: websocket', 'Connection: Upgrade', `Sec-WebSocket-Accept: ${acceptKey}`, '\r\n' ].join('\r\n');
socket.write(response);
// Connection is now WebSocket - handle frames socket.on('data', (frame) => { // Parse and handle WebSocket frames console.log('WebSocket frame received'); }); } });});
server.listen(3000);Frequently Asked Questions
What's the most common use of 101 Switching Protocols?
By far, upgrading HTTP connections to WebSocket for real-time, bidirectional communication. This is used in chat applications, live feeds, collaborative editing, online gaming, and any scenario requiring instant data updates without polling.
Can any HTTP connection be upgraded to WebSocket?
Not necessarily. Both client and server must support WebSocket, the server must be configured to handle upgrades, and intermediate proxies must allow the connection through. HTTP/2 connections cannot be upgraded using this mechanism - they use ALPN instead.
What happens to the connection after 101 is sent?
The TCP connection remains open, but HTTP semantics are completely replaced by the new protocol. You can no longer send HTTP requests/responses on that connection - it now speaks the upgraded protocol (like WebSocket) exclusively until closed.
Why does WebSocket need the Sec-WebSocket-Accept header?
It proves the server actually understands WebSocket protocol and isn't just a generic HTTP server echoing headers. The server must correctly hash the client's key with a magic GUID - only WebSocket-aware servers can generate the correct accept value.
Can I downgrade back to HTTP after a 101 upgrade?
No, protocol upgrades are one-way and irreversible for that connection. Once you've switched to WebSocket (or another protocol), you must close the connection and establish a new one to use HTTP again.
Common Causes
- Client initiating WebSocket connection with Upgrade: websocket header
- HTTP/2 cleartext (h2c) upgrade request, though uncommon in production
- Custom protocol upgrades for specialized real-time applications
- MQTT over WebSocket connections for IoT applications
Implementation Guidance
- If 101 appears unexpectedly, verify your client isn’t accidentally sending Upgrade headers
- Ensure your server correctly implements the WebSocket handshake per RFC 6455
- Check that Sec-WebSocket-Key and Sec-WebSocket-Accept are properly calculated
- Verify intermediate proxies support WebSocket and don’t interfere with upgrades
- Use wss:// (WebSocket Secure) in production for TLS encryption
- Implement Origin header validation to prevent unauthorized WebSocket connections
- Handle WebSocket frame parsing correctly after the protocol switch
- For debugging, use browser DevTools Network tab to inspect the upgrade handshake