101 Switching Protocols oznacza, że serwer przyjmuje nagłówek żądania Upgrade wysłany przez klienta. Zaraz po pustym wierszu kończącym odpowiedź 101 obie strony zaczynają komunikować się w tym połączeniu innym protokołem. Odpowiedź musi zawierać nagłówek Upgrade z nazwą nowego protokołu.
Obecnie jest to niemal zawsze uzgadnianie połączenia WebSocket (handshake). Przeglądarka wysyła żądanie GET z nagłówkami Upgrade: websocket, Connection: Upgrade i Sec-WebSocket-Key. Serwer odpowiada kodem 101 z pasującym nagłówkiem Sec-WebSocket-Accept i od tej chwili obie strony wymieniają ramki WebSocket. Kod 101 służył też do przełączania h2c z nieszyfrowanego HTTP/1.1 na HTTP/2 – mechanizmu, który jest dziś wycofany. Przeglądarki negocjują zamiast tego HTTP/2 i HTTP/3 podczas uzgadniania TLS (ALPN).
Mechanizm Upgrade istnieje tylko w HTTP/1.1. HTTP/2 i HTTP/3 nigdy nie wysyłają kodu 101; WebSockety w tych protokołach korzystają z rozszerzonej metody CONNECT (RFC 8441 i RFC 9220).
Przykładowa odpowiedź
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=SEO i sprawdzanie przekierowań
Kod 101 nigdy nie jest wynikiem zwykłego żądania strony. Przeglądarki i roboty indeksujące otrzymują go tylko wtedy, gdy wprost poproszą o przełączenie połączenia, więc nie ma on wpływu na indeksowanie. Narzędzie do sprawdzania przekierowań wysyła zwykłe żądania GET, HEAD lub POST i nie zobaczy kodu 101. Jeśli sprawdzisz endpoint WebSocket jak zwykły adres URL, zazwyczaj odpowie on kodem 4xx, np. 426 Upgrade Required lub 400 Bad Request.
Typowe przyczyny i zastosowania
- Przeglądarka otwiera połączenie WebSocket (
new WebSocket('wss://...')), a serwer akceptuje handshake. - Klient prosi o przestarzałe przełączenie
h2cna nieszyfrowane HTTP/2, a serwer je obsługuje. - WebSockety nie działają za reverse proxy, bo proxy nie przekazuje nagłówków
UpgradeiConnection. W nginx ustawproxy_http_version 1.1i przekaż oba nagłówki do backendu.