# 101 Switching Protocols et la poignée de main WebSocket

> 101 Switching Protocols confirme que le serveur accepte une demande Upgrade, le plus souvent pour passer la connexion de HTTP/1.1 à WebSocket.

URL: https://yes-seo.com/fr/codes-http/101

**101 Switching Protocols** signifie que le serveur a accepté la demande du client de changer de protocole sur la connexion en cours. Juste après le 101, les deux parties cessent de parler HTTP/1.1 et adoptent le nouveau protocole, qui est presque toujours WebSocket dans la pratique.

## Comment fonctionne le changement de protocole

La [RFC 9110, section 15.2.2](https://www.rfc-editor.org/rfc/rfc9110#section-15.2.2) associe le 101 à l’en-tête `Upgrade` : le serveur ne change de protocole que si le client le demande, et il doit renvoyer un en-tête `Upgrade` nommant le protocole qui prend le relais. La poignée de main WebSocket de la RFC 6455 en est l’exemple le plus connu :

```
GET /chat HTTP/1.1
Host: app.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

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

Le code 101 appartient à HTTP/1.1. HTTP/2 ne le prend plus en charge : les WebSockets sur HTTP/2 passent par une requête CONNECT étendue (RFC 8441).

## Pourquoi le changement de protocole échoue

- Un proxy inverse ou un répartiteur de charge supprime les en-têtes `Upgrade` et `Connection`, qui ne valent que pour un seul saut. L’application voit alors une requête ordinaire et répond 200 ou [400](https://yes-seo.com/fr/codes-http/400) au lieu de 101.

- Le proxy ferme les connexions inactives après son délai de lecture, ce qui coupe les sockets en cours d’utilisation.

- Un CDN ou une offre d’hébergement n’autorise pas les WebSockets sur ce nom d’hôte.

Avec Nginx placé devant une application Node.js ou Python, transmettez explicitement les en-têtes :

```
location /ws/ {
    proxy_pass http://127.0.0.1:3000;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_read_timeout 3600s;
}
```

## Impact SEO

Un 101 ne s’applique jamais à la page elle-même. Les robots demandent le HTML avec de simples requêtes GET et reçoivent un statut final normal. Le risque concerne le contenu : un texte qui n’arrive que par WebSocket après le chargement de la page ne figure pas dans le HTML serveur que lisent de nombreux robots, et nos outils. Placez titres, texte et liens dans la réponse initiale (voir [SEO JavaScript](https://yes-seo.com/fr/glossaire/seo-javascript)) et réservez le socket aux mises à jour en direct. Vérifiez que l’URL de la page renvoie bien [200](https://yes-seo.com/fr/codes-http/200) avec le [vérificateur de statut HTTP](https://yes-seo.com/fr/verificateur-code-http).

## Questions fréquentes

### Le code 101 Switching Protocols est-il une erreur ?

Non. Il indique qu’un changement de protocole a réussi, en général une poignée de main WebSocket. Dans les outils de développement du navigateur, une connexion WebSocket qui fonctionne affiche le statut 101.

### Pourquoi mon WebSocket reçoit-il 200 ou 400 au lieu de 101 ?

Les en-têtes Upgrade et Connection se sont perdus en route, le plus souvent au niveau d’un proxy inverse ou d’un répartiteur de charge non configuré pour les WebSockets. Il se peut aussi que l’URL ne soit pas du tout un point d’accès WebSocket.

### HTTP/2 utilise-t-il le code 101 Switching Protocols ?

Non. HTTP/2 a supprimé la prise en charge du 101. Sur HTTP/2, les WebSockets s’ouvrent avec une requête CONNECT étendue, définie dans la RFC 8441.