HTTP 101 Switching Protocols – Free, Online, Private

What HTTP 101 means

101 is the server's agreement to leave HTTP on this TCP connection. The client asked with an Upgrade header, often websocket, and sometimes h2c. The 101 response is the last HTTP message. Bytes after it belong to the new protocol. Sending a normal HTTP request next on the same connection is a bug.

101 Switching Protocols belongs to the 1xx informational class. Clients that only look at the class will group it with its neighbors. Clients that care about the exact code should use the narrower rule on this page, because the class is only the first digit.

When you see HTTP 101

When you see HTTP 101 Switching Protocols, stop on that exact status line. 101 Switching Protocols accepts an Upgrade and changes the protocol on this connection. The trace that usually produces it: A WebSocket handshake succeeded and the server computed the accept key. The 1xx informational class only tells you the first digit. A neighbor in that class is a different fault, and the fix on this page does not transfer to it.

Return 101 only when you are actually switching, and only after you accept the Upgrade token and any required handshake, such as Sec-WebSocket-Accept. If you will not switch, ignore the Upgrade and answer the HTTP request normally. Do not use 101 as a redirect.

How to fix HTTP 101

To fix HTTP 101, change the condition that made the server choose Switching Protocols. Stop speaking HTTP after a valid 101. If the accept key is wrong, close the connection. Do not follow 101 with a second request on the same socket. A failed handshake is not retried as a normal GET. Open a new connection and start the handshake again. Retrying the already-switched connection will not work. If the log line is a different code, leave this page. The mix-up people make with 101 is this one: 426 Upgrade Required is the opposite direction: the server is refusing the current protocol and telling the client to upgrade. 101 means the upgrade already succeeded.

• A client offered a protocol the server does not want, and a buggy server sent 101 anyway.
• A proxy stripped Upgrade and the origin's 101 never reached the browser, so the client hung.
• The server sent 101 and then wrote another HTTP response, which the client tried to parse as a WebSocket frame.

An access log that only stores 101 is not enough to tell these apart. Keep the method, the path, and a request id. Do not keep the Authorization header or a request body that might be a token. The status explains the outcome. It is not a place to echo secrets back to the client either.

Example response

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

Upgrade names the new protocol. Connection: Upgrade is required so proxies do not treat the header as end-to-end. For WebSocket the accept value is a hash of the client's key. After the blank line the connection is no longer HTTP.

What the client should do

Stop speaking HTTP after a valid 101. If the accept key is wrong, close the connection. Do not follow 101 with a second request on the same socket.

101 must not be cached. It is a property of one connection, not of a URL.

A failed handshake is not retried as a normal GET. Open a new connection and start the handshake again. Retrying the already-switched connection will not work.

Codes people confuse with HTTP 101

426 Upgrade Required is the opposite direction: the server is refusing the current protocol and telling the client to upgrade. 101 means the upgrade already succeeded.