200 OK : ce que ça signifie et ce que ça cache

Ce que garantit un 200

Un 200 est le statut de succès standard. Il vous dit un ensemble étroit et précis de choses : le DNS s'est résolu, une connexion TCP a été établie, le TLS a négocié si l'URL était en HTTPS, le serveur a accepté la ligne de requête et les en-têtes, et il a produit une réponse qu'il considère réussie. Pour un GET, le corps est la ressource demandée ; pour un POST, c'est le résultat de l'action.

Ce qu'un 200 ne vous dit pas, c'est si la page contient le catalogue produit, si le formulaire de paiement s'est affiché, si le JavaScript qui remplit la page a reçu ses données, ou si la réponse que vous avez obtenue est celle que vos visiteurs dans un autre pays obtiennent. Tout cela vit dans le corps, et le code de statut ne regarde jamais le corps.

Le 200 qui est en réalité un échec

La surveillance de code de statut à elle seule ne suffit pas, car un site cassé répond 200 dans tous ces cas :

• Une page de maintenance. Délibérément servie en 200 par un script de déploiement ou une règle de CDN. La disponibilité paraît parfaite pendant toute la fenêtre de panne.
• Une exception applicative interceptée. Le framework capture l'erreur et affiche une page conviviale « quelque chose s'est mal passé » via le pipeline de gabarit normal, qui définit le statut par défaut de 200.
• Un faux 404. Un message « page introuvable » renvoyé en 200 au lieu de 404. Les visiteurs sont désorientés et les moteurs de recherche peuvent continuer à indexer l'URL ou traiter tout le motif comme de faible qualité.
• Une coquille vide rendue côté client. Le document HTML se charge bien, mais l'appel API qui le remplit a échoué. Le statut est 200 et la page est vide.
• Une copie en cache périmée ou dans la mauvaise langue. Un nœud de bordure dont la récupération vers l'origine a échoué continue de servir ce qu'il a déjà, en 200.
• Un domaine parqué ou détourné. Après un changement DNS, il répond 200 avec le contenu de quelqu'un d'autre.

Un 200 lent reste un problème

Le temps de réponse compte souvent plus que le code. Une page qui met douze secondes à renvoyer 200 est fonctionnellement en panne pour la plupart des visiteurs, qui seront partis avant qu'elle ne finisse. Le code de statut n'a aucune dimension temporelle, donc vous devez mesurer le temps de réponse et lui fixer un seuil séparément. La taille mérite d'être surveillée pour la même raison : un 200 qui renvoie 300 octets là où il en renvoie normalement 80 Ko est un signal fort que la page s'est rendue sans son contenu.

Comment vérifier qu'un 200 est un vrai succès

1. Lisez la ligne de statut et le chronométrage ensemble :

   curl -sI -o /dev/null -w "%{http_code} in %{time_total}s\n" https://example.com/

2. Récupérez le corps et faites une assertion sur une chaîne qui n'apparaît que quand la page fonctionne véritablement, comme un titre, un prix ou un repère de pied de page, plutôt que sur quelque chose que le gabarit d'erreur contient aussi.
3. Faites une assertion sur l'absence autant que sur la présence. Rechercher des phrases telles que « en maintenance », « temporairement indisponible » ou le texte d'exception de votre framework détecte le cas de l'erreur conviviale.
4. Comparez la taille de la réponse à une référence connue comme correcte. Un effondrement soudain de la longueur du corps signifie généralement que la coquille s'est rendue et pas le contenu.
5. Vérifiez une page profonde, pas seulement la page d'accueil. Les pages d'accueil sont les plus fortement mises en cache et les plus susceptibles de continuer à répondre 200 pendant que l'application derrière elles est cassée.
6. Répétez depuis plus d'un réseau. Un 200 depuis votre bureau et une erreur depuis un autre continent pointent vers le DNS, le CDN ou le routage géographique plutôt que vers l'application elle-même.

Ce qu'une vérification de disponibilité verte peut manquer

Un moniteur qui ne lit que le code de statut rapportera un site vert pendant tout un incident qui a commencé par une page de maintenance que personne n'a retirée. Associer la vérification de statut à une assertion de mot-clé et à un seuil de temps de réponse est ce qui transforme « le serveur a répondu » en « la page a fonctionné ». HostTracker propose 13 types de moniteurs et alerte par e-mail, SMS, appel vocal, Slack, Telegram et bien plus, donc une incohérence de contenu déclenche la même alerte qu'une panne le ferait. Passez une URL dans l'outil de vérification HTTP pour voir son statut, ses en-têtes et son chronométrage, ou lisez la famille 2xx et 500 Internal Server Error pour les réponses qu'une page d'erreur conviviale peut cacher.