http.app
Zero Data Retention

HTTP 101 SWITCHING PROTOCOLS

The server agrees to change protocol, as in the WebSocket upgrade handshake. 101 belongs to the 1xx informational class and is defined in RFC 9110.

Zero retention: your headers never leave this browser. Verify it yourself in DevTools.

Loading the workbench.

About HTTP 101

What Does HTTP 101 Switching Protocols Mean?

The server agrees to change protocol, as in the WebSocket upgrade handshake. The code is registered with IANA and defined in RFC 9110.

Informational: the request was received and the process continues. Every code from 100 to 199 shares that general meaning, so a client that does not recognise 101 must treat it like 100.

When Do You See a 101 Response?

101 Switching Protocols is the server agreeing to change the protocol of the current connection. Almost every 101 you will meet is a WebSocket handshake: the browser sends Upgrade: websocket with Connection: Upgrade and a Sec-WebSocket-Key, and the server switches. The older h2c upgrade from cleartext HTTP/1.1 to HTTP/2 also used it, but browsers never supported that path. After a 101 the bytes on the wire are no longer HTTP.

How Do You Handle a 101?

A server must include an Upgrade header naming the protocol it switched to and, for WebSockets, a Sec-WebSocket-Accept value derived from the client key. If a WebSocket connection fails right after the handshake, check that every proxy and load balancer in front of the app forwards the Upgrade and Connection headers, since many strip hop-by-hop headers by default. HTTP/2 connections use extended CONNECT instead of 101.

What Does a 101 Response Look Like?

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

101 is not cacheable by default: a browser or CDN stores it only when Cache-Control or Expires explicitly allows it.

To inspect a real one without sending it anywhere:

  1. Copy the response headers from your browser Network tab, or from curl -i.
  2. Paste them into the Header decoder to see every header explained.
  3. Check caching in the Cache lane.

Which Status Codes Are Related to 101?

  • 426 Upgrade Required: The client must switch protocols, named in the Upgrade header.
  • 100 Continue: The headers were fine; send the body. Used with Expect: 100-continue so a client does not upload a large body that would be rejected.
  • 200 OK: The request succeeded. The body depends on the method.

Browse every code on the HTTP status codes page.

What Other Lanes Are in the Reference Section?

  • HTTP status codes: Every IANA-registered status code, with a page per code.
  • MIME types: File extensions to Content-Type, searchable both ways, plus a Content-Type parser.
  • HTTP methods: GET, POST, PUT, PATCH, DELETE and the rest: safe, idempotent, cacheable.

Elsewhere in 2http: Header decoder, Cookie decoder, Cache-Control decoder, CORS checker, User-agent parser, and all eleven lanes on the 2http home page. Part of the 2suite.io privacy-first ecosystem.

Frequently Asked Questions

Why does my WebSocket get 200 instead of 101?

The upgrade request never reached a WebSocket-aware handler. A proxy probably dropped the Upgrade and Connection headers, or the route served a normal page. Configure the proxy to pass those headers through.

Can a browser use 101 to switch to HTTP/2?

No. Browsers only speak HTTP/2 over TLS, negotiated with ALPN during the handshake. The cleartext h2c upgrade via 101 was used by some servers and tools but has been deprecated.

Is HTTP 101 an error?

No. 101 is a informational response, not an error.

Is a 101 response cacheable by default?

No. Caches store a 101 only when Cache-Control or Expires explicitly allows it.

How Can You Verify That Nothing Leaves This Browser?

You do not have to take our word that your headers stay here. Developer tools show every request a page makes, so you can watch this page work and confirm that nothing is sent. The check takes under a minute.

  1. Open your browser developer tools with F12, or Cmd+Option+I on a Mac, and select the Network tab.
  2. Reload the page and let it finish. You will see the page's own files, its web fonts, and one anonymous page-view request. Nothing has been typed yet, so none of them can contain your headers.
  3. Click the clear icon in the Network tab so that the log is empty.
  4. Paste real headers into any lane and read the result.
  5. Look at the Network tab again. It is still empty. For extra proof, turn on offline mode after the page loads and every lane keeps working.

Only two things can add a line to that log, and neither carries your headers. Submitting the feedback form sends the vote and comment you typed. Typing characters in a script the page has not displayed yet, such as Cyrillic or Greek, can make the browser fetch the matching font file, and that request names only the font.

2http never sends a request on your behalf: the request builder writes code for you to run, and the meta inspector reads source you paste instead of fetching a URL. The production site also sends a Content-Security-Policy header that tells your browser to refuse connections to anywhere except this site and the anonymous analytics endpoint.

Was this helpful?