101 Switching Protocols indica che il server accetta l’intestazione di richiesta Upgrade inviata dal client. Subito dopo la riga vuota che chiude la risposta 101, le due parti parlano un protocollo diverso su questa connessione. La risposta deve contenere un’intestazione Upgrade che indica il nuovo protocollo.
Oggi si tratta quasi sempre dell’handshake WebSocket. Il browser invia un GET con Upgrade: websocket, Connection: Upgrade e una Sec-WebSocket-Key. Il server risponde 101 con il corrispondente Sec-WebSocket-Accept e da quel momento le due parti si scambiano frame WebSocket. Il 101 veniva usato anche per l’upgrade h2c da HTTP/1.1 in chiaro a HTTP/2, oggi deprecato. I browser, invece, negoziano HTTP/2 e HTTP/3 durante l’handshake TLS (ALPN).
Il meccanismo Upgrade esiste solo in HTTP/1.1. HTTP/2 e HTTP/3 non inviano mai 101; i WebSocket su questi protocolli usano il CONNECT esteso (RFC 8441 e RFC 9220).
Esempio di risposta
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=SEO e verifica dei redirect
Un 101 non è mai il risultato di una normale richiesta di pagina. Browser e crawler lo ricevono solo quando chiedono esplicitamente di passare a un altro protocollo sulla connessione, quindi non ha alcun effetto sull’indicizzazione. Una verifica redirect invia semplici richieste GET, HEAD o POST e non vedrà mai un 101. Se un endpoint WebSocket viene verificato come un normale URL, di solito risponde con un codice 4xx come 426 Upgrade Required o 400 Bad Request.
Cause comuni e casi d’uso
- Un browser apre un WebSocket (
new WebSocket('wss://...')) e il server accetta l’handshake. - Un client richiede l’upgrade deprecato
h2ca HTTP/2 in chiaro e il server lo supporta. - I WebSocket non funzionano dietro un reverse proxy perché il proxy non inoltra le intestazioni
UpgradeeConnection. In nginx impostaproxy_http_version 1.1e passa entrambe le intestazioni al backend.