Codes de statut informationnels 1xx

Ce qu'est une réponse intermédiaire

Chaque autre famille de statut termine l'échange. Un 200, un 404 ou un 502 est le dernier mot du serveur sur cette requête. Un 1xx est différent : le serveur envoie la ligne de statut et d'éventuels en-têtes, puis garde la connexion ouverte et envoie une seconde réponse plus tard. La RFC 9110 exige que les clients soient capables de lire une ou plusieurs réponses 1xx avant la réponse finale, et elle permet à tout client qui ne comprend pas un code 1xx particulier de l'ignorer.

La réponse intermédiaire est jetée dès que la réponse finale arrive, donc la plupart des outils ne la montrent jamais. Le panneau réseau de votre navigateur, le journal d'accès de votre serveur web et une vérification de surveillance rapportent tous le statut final. La réponse intermédiaire a fait son travail au niveau du transport et a disparu.

Les codes 1xx que vous pouvez rencontrer

• 100 Continue. Le client a envoyé des en-têtes de requête avec Expect: 100-continue et a fait une pause avant d'envoyer un corps volumineux. Un 100 signifie « les en-têtes ont l'air corrects, envoyez le corps ». Si le serveur devait de toute façon rejeter la requête, il peut répondre par une erreur finale à la place et le client ne gaspille jamais de bande passante à envoyer la charge utile. C'est le seul code 1xx qui accomplit un travail utile sur des sites ordinaires, généralement derrière les envois de fichiers volumineux et les clients d'API tels que curl.
• 101 Switching Protocols. Le client a demandé un changement de protocole avec un en-tête Upgrade et le serveur a accepté. C'est l'issue normale et réussie d'une poignée de main WebSocket, donc un 101 dans un journal est en général bon signe, pas un incident.
• 102 Processing. Défini par la spécification WebDAV pour les requêtes longues, afin que le client sache que le serveur ne s'est pas bloqué. Il est rarement implémenté en dehors de WebDAV et vous avez peu de chances de le rencontrer sur un site web normal.
• 103 Early Hints. Le serveur envoie des en-têtes Link tôt, avant d'avoir fini de générer la page, pour que le navigateur puisse commencer à précharger les feuilles de style, les polices ou les scripts pendant que le HTML est encore en cours de production. C'est une fonctionnalité de performance, pas un signal d'erreur, et vous l'activez normalement de façon délibérée au niveau du CDN ou de l'origine.

Pourquoi un 1xx n'est pas quelque chose à corriger

Un 1xx en lui-même ne porte aucune faute. Il n'existe pas de page qui « renvoie 100 » ou « renvoie 101 » de la même façon qu'une page peut renvoyer 404. Si vous avez un problème et qu'un 1xx se trouve quelque part dans l'échange, l'information intéressante est toujours le code de statut final qui a suivi, ou le fait qu'aucune réponse finale n'est arrivée du tout.

Les vrais modes de défaillance près des 1xx se manifestent comme un blocage ou une erreur finale plutôt que comme le 1xx lui-même :

• Un vieux proxy ou répartiteur de charge qui ne transmet pas les réponses intermédiaires, si bien qu'un client attendant 100 Continue se bloque jusqu'à ce que son propre timeout se déclenche.
• Une mise à niveau WebSocket qui n'atteint jamais un 101 parce qu'un proxy devant l'application retire les en-têtes Upgrade et Connection. La connexion se replie alors ou échoue franchement.
• Des early hints émis avec des liens vers des ressources qui n'existent plus, ce qui gaspille des requêtes sans casser la page.

Comment voir vous-même une réponse 1xx

1. Utilisez un client verbeux. Le curl -I ordinaire ne montre que les en-têtes de la réponse finale, donc demandez plutôt l'échange complet :

   curl -v -H "Expect: 100-continue" --data-binary @big.bin https://example.com/upload

   Un serveur coopératif répond HTTP/1.1 100 Continue avant que le corps ne parte, puis le 2xx ou 4xx final.
2. Pour un chemin WebSocket, vérifiez que la poignée de main atteint HTTP/1.1 101 Switching Protocols. Si ce n'est pas le cas, regardez d'abord la couche proxy : les en-têtes de mise à niveau sont de type saut par saut, et plusieurs configurations courantes de proxy inverse les suppriment par défaut.
3. Pour les early hints, demandez la page et cherchez un bloc 103 avant la réponse finale. Tous les intermédiaires ne le transmettent pas, donc l'absence d'un 103 ne signifie pas toujours que l'origine n'en envoie pas.
4. Si un envoi volumineux se bloque sans aucune réponse du tout, réessayez sans l'en-tête Expect. Si le nouvel essai réussit, quelque chose entre vous et l'origine avale les réponses intermédiaires.

Surveiller un échange que vous ne pouvez pas voir

Comme les codes 1xx n'atteignent jamais un journal ou un tableau de bord, ce que vous surveillez, c'est la réponse finale et le temps qu'elle a mis à arriver. Un chemin d'envoi bloqué sur une réponse intermédiaire ressemble de l'extérieur exactement à un point de terminaison lent ou qui expire, et une vérification externe le voit immédiatement. HostTracker exécute des vérifications depuis plus de 300 points de contrôle dans 158 villes, donc une requête qui se bloque derrière un chemin réseau particulier se distingue d'une vraie panne. Passez une URL dans l'outil de vérification HTTP pour voir le statut final et le temps de réponse. Les guides codes de succès 2xx et codes de redirection 3xx couvrent les réponses qui terminent réellement un échange.