101 Switching Protocols betekent dat de server de Upgrade-requestheader van de client accepteert. Direct na de lege regel waarmee de 101-response eindigt, spreken beide kanten een ander protocol over deze verbinding. De response moet een Upgrade-header bevatten die het nieuwe protocol noemt.
Tegenwoordig gaat het bijna altijd om de WebSocket-handshake. De browser stuurt een GET met Upgrade: websocket, Connection: Upgrade en een Sec-WebSocket-Key. De server antwoordt met 101 en de bijbehorende Sec-WebSocket-Accept, en vanaf dat moment wisselen beide kanten WebSocket-frames uit. 101 werd ook gebruikt voor de h2c-upgrade van onversleuteld HTTP/1.1 naar HTTP/2, die inmiddels verouderd is. Browsers onderhandelen in plaats daarvan tijdens de TLS-handshake (ALPN) over HTTP/2 en HTTP/3.
Het Upgrade-mechanisme bestaat alleen in HTTP/1.1. HTTP/2 en HTTP/3 sturen nooit een 101; WebSockets over die protocollen gebruiken extended CONNECT (RFC 8441 en RFC 9220).
Voorbeeldresponse
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=SEO en redirects controleren
Een 101 is nooit het resultaat van een gewoon paginaverzoek. Browsers en crawlers krijgen deze code alleen als ze expliciet vragen om de verbinding te upgraden, dus heeft die geen invloed op de indexering. Een redirectchecker stuurt gewone GET-, HEAD- of POST-verzoeken en ziet nooit een 101. Controleer je een WebSocket-endpoint als een normale URL, dan antwoordt het meestal met een 4xx-code zoals 426 Upgrade Required of 400 Bad Request.
Veelvoorkomende oorzaken en toepassingen
- Een browser opent een WebSocket (
new WebSocket('wss://...')) en de server accepteert de handshake. - Een client vraagt de verouderde
h2c-upgrade naar onversleuteld HTTP/2 aan en de server ondersteunt die. - WebSockets werken niet achter een reverse proxy, omdat de proxy de headers
UpgradeenConnectionniet doorgeeft. Stel in nginxproxy_http_version 1.1in en geef beide headers door aan de backend.