API Status Explained

HTTP Status Code 101 — Switching Protocols

When working with APIs, you mostly see response codes like 200 OK, 400 Bad Request, and 500 Internal Server Error. These are straightforward — the server either succeeded or failed.

But some responses are more about how the communication continues than about success or failure. HTTP Status Code 101: Switching Protocols is one of them.

This blog will help you understand:

  • What 101 Switching Protocols means
  • Why APIs use protocol upgrades
  • Real-life use cases
  • What testers should verify
  • How to simulate a 101 response
  • Header-level details (Sec-WebSocket-* explained)

What Does Status Code 101 Mean?

Status Code 101: Switching Protocols indicates that the client requested to change the communication protocol during an HTTP request, and the server agreed.
It’s like starting a regular chat and then saying:

  • “Let’s switch to a video call for better experience.”

If both agree → the communication switches formats without disconnecting.
That’s exactly what happens with HTTP → WebSocket upgrades.

Why Would a Client Request a Protocol Switch?

HTTP is request → response → done.
It is not ideal for real-time applications where both sides need to talk anytime (over a single connection).
Examples:

  • Live chat messaging
  • Live stock & crypto price dashboards
  • Multiplayer game updates
  • GPS location tracking in delivery apps
  • Sports score updates
  • Collaborative editing tools

WebSockets solve this by allowing:

  • Always-on connection
  • Low-latency real-time communication
  • Continuous data streaming

HTTP merely initiates the handshake. WebSockets power the actual real-time updates.

How the 101 Switching Protocols Response Works

Here’s what a WebSocket upgrade request looks like:

Client → Server
GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: abc123==

Server → Client
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: xyz456==

Once the server sends 101,

  • Protocol switches
  • WebSocket communication begins

The server does not finish the transaction here. It simply says: “Yes, let’s continue using a different protocol.”

The Security Headers: Sec-WebSocket-*

Because switching protocols is risky, WebSockets include special headers.

Header Sent By Purpose
Sec-WebSocket-Key Client Random value to verify the request
Sec-WebSocket-Accept Server Hashed version of the key to prove authenticity
Sec-WebSocket-Version Client Supported WebSocket version (13 is standard)
Sec-WebSocket-Protocol Both Optional — negotiate chat v1, chat v2 etc.
Sec-WebSocket-Extensions Both e.g., compression settings

These ensure:
✔ The server actually supports WebSockets
✔ The connection is not accidentally hijacked by intermediaries
✔ Both parties speak the same format

Real-Life Example: Food Delivery App

Imagine you are ordering food on Zomato or Swiggy:

1. You place the order → HTTP request

2.You see live updates of the delivery rider’s location


That live map is powered by:

1. WebSockets

2. Server-Push updates

Without WebSockets:
It would need multiple HTTP polls → slower + costly

So your browser upgrades from:
HTTP → WebSocket → real-time tracking

That moment of switching?
Status Code 101!

What Testers Should Validate for 101

Testing WebSockets is different from testing normal APIs. Here’s a useful checklist:

What to verify Why it matters
Request contains upgrade headers Else server won't switch
Response must be 101 status Successful protocol negotiation
Sec-WebSocket-Accept must match Prevents invalid or insecure connections
Connection stays open after handshake Required for real-time messaging
Data exchange format after switch WebSocket messaging, not JSON HTTP responses
Proper closure behavior WebSocket close codes must be correct

Testing failures:

  • Missing headers → expect 400/426
  • Unsupported version → expect 426 Upgrade Required
  • Server refusing upgrade → 403/404

How to Simulate 101 as a Tester

Most manual testing tools don’t fully support WebSockets. But you can still test the below scenario:

1. Add upgrade headers
2. Send GET request
3. Validate 101 Switching Protocols response





Related topics