Codes de statut de succès 2xx

Ce que couvre la famille 2xx

Le succès n'est pas une condition unique. Un navigateur récupérant une page, un formulaire publiant un nouvel enregistrement, une tâche en arrière-plan acceptant du travail pour plus tard et un lecteur vidéo demandant les octets 5 000 000 à 6 000 000 sont tous des succès, mais ils ont besoin de réponses différentes. C'est ce que les codes 2xx encodent. La RFC 9110 définit 200 à 206 ; une poignée d'autres viennent d'extensions comme WebDAV.

Pour le trafic web quotidien, l'écrasante majorité des réponses réussies sont de simples 200. Le reste compte surtout pour les clients d'API, les chemins d'upload et la diffusion de médias.

Les codes 2xx et quand chacun apparaît

• 200 OK. Le succès standard. Pour un GET, le corps est la ressource demandée ; pour un POST, c'est le résultat de l'action. C'est ce que renvoie une page saine.
• 201 Created. La requête a créé une nouvelle ressource. Une API bien conçue renvoie 201 avec un en-tête Location pointant vers ce qu'elle vient de créer. Vous voyez cela dans les journaux d'API, rarement dans un navigateur.
• 202 Accepted. La requête a été acceptée pour traitement mais n'est pas terminée. Utilisé pour du travail asynchrone comme un import en masse ou un rapport qui sera généré en arrière-plan. Un 202 est une promesse, pas un résultat, donc le client doit normalement interroger une URL de statut.
• 203 Non-Authoritative Information. Succès, mais un proxy ou un intermédiaire transformant a modifié la réponse en chemin. Rare sur les sites modernes.
• 204 No Content. Succès sans corps, délibérément. Typique pour un DELETE, un PUT qui a enregistré sans avoir besoin de renvoyer quoi que ce soit, ou un endpoint d'enregistrement automatique. Le navigateur reste sur la page actuelle.
• 205 Reset Content. Succès, et le client devrait réinitialiser le formulaire ou la vue de document qui a envoyé la requête. Rarement utilisé en pratique.
• 206 Partial Content. Le serveur ne renvoie que la plage d'octets que le client a demandée avec un en-tête Range. C'est ainsi que fonctionnent la recherche dans une vidéo, les téléchargements reprenables et les transferts de gros fichiers, donc 206 est normal et attendu sur les endpoints de médias.
• 207 Multi-Status et 208 Already Reported viennent de WebDAV, où une requête peut agir sur de nombreuses ressources et doit rapporter un résultat par ressource. 226 IM Used vient de l'extension d'encodage delta et est très rarement déployé.

Pourquoi un 200 ne prouve pas que la page est saine

Un code de statut décrit le résultat de la transaction HTTP, pas la justesse de ce qui est revenu. Une page à l'enseigne « nous sommes en maintenance » est servie avec un 200. Une page d'erreur d'application aussi, quand le framework attrape l'exception et rend une excuse aimable via le gabarit normal avec son statut par défaut. Une page rendue côté client dont l'appel d'API a échoué renvoie 200 pour la coquille vide autour du contenu manquant, et un soft 404 renvoie 200 pour un message « page introuvable », ce qui trouble aussi les moteurs de recherche.

Dans chacun de ces cas, une vérification de code de statut signale un succès alors que vos visiteurs voient un site cassé. La correction est une vérification de contenu : vérifier qu'une chaîne connue est présente dans le corps de la réponse, ou qu'une chaîne d'erreur connue en est absente, en plus de vérifier le code.

Comment vérifier ce qu'une URL renvoie réellement

1. Demandez seulement les en-têtes et lisez la ligne de statut :

   curl -sI https://example.com/ | head -n 1

2. Si c'est un 200, récupérez aussi le corps et confirmez qu'il contient ce qu'il devrait. Cherchez une chaîne qui n'apparaît que sur une page fonctionnelle, comme un titre ou un repère de pied de page.
3. Pour un endpoint d'API, vérifiez que le code correspond à la sémantique : une création devrait être 201 avec un Location, une suppression devrait être 204, et une tâche longue devrait être 202 avec une URL de statut.
4. Pour les médias, confirmez que le serveur annonce Accept-Ranges: bytes et répond à une requête par plage avec 206. S'il répond 200 à une requête par plage, la recherche dans le fichier sera lente car le fichier entier est renvoyé à chaque fois.
5. Répétez la vérification depuis un autre réseau. Une réponse qui est 200 pour vous et une erreur ailleurs pointe vers le DNS, le CDN ou le routage géographique plutôt que vers l'application.

Vérifier le corps, pas seulement le code

Une vérification de code de statut signalera un site vert qui sert une page d'erreur, donc associez-la à une assertion de contenu sur la même requête. HostTracker surveille des sites web depuis 2004 et propose 13 types de moniteurs, donc une URL peut être surveillée pour son code de statut, pour un mot-clé dans la réponse et pour le temps de réponse à la fois. Passez une URL dans l'outil de vérification HTTP pour voir le code et les en-têtes qu'elle renvoie à l'instant, puis lisez ce que signifie vraiment un 200 OK et les codes d'erreur serveur 5xx pour les échecs qu'un 200 peut masquer.