Codes d’état HTTP expliqués

Chaque fois qu’un navigateur, une application ou un outil de surveillance demande quelque chose à un serveur web, le serveur commence sa réponse par un code d’état. C’est un court nombre qui résume le résultat : ça a marché, allez ailleurs, vous avez fait une erreur, ou c’est le serveur qui a échoué.

Le premier chiffre donne la famille, et la famille suffit généralement à comprendre la situation.

Les cinq familles

« Erreur du client » ne veut pas dire que le visiteur est fautif. Un lien cassé sur votre propre site produit une 404, et c’est quand même à votre site de le corriger.

1xx : information

Ce sont des réponses intermédiaires. 100 Continue et 101 Switching Protocols en sont des exemples. Les vérifications de page ordinaires n’en rencontrent presque jamais, car la réponse finale suit.

2xx : succès

• 200 OK. La requête a réussi et la réponse contient le contenu. C’est le résultat normal pour une page qui fonctionne.
• 204 No Content. La requête a réussi et il n’y a rien à renvoyer. Courant pour les API.

3xx : redirections

Une redirection dit au client de demander ailleurs. La nouvelle adresse arrive dans l’en-tête Location.

• 301 Moved Permanently. L’adresse a changé définitivement. Les navigateurs et les moteurs de recherche sont censés utiliser la nouvelle. Usage typique : déplacer un site vers un nouveau domaine, ou forcer https.
• 302 Found. Un déplacement temporaire. Les clients doivent continuer à utiliser l’adresse d’origine à l’avenir.
• 304 Not Modified. Pas un déplacement : le contenu n’a pas changé, le client peut donc utiliser sa copie en cache.

Il y a deux autres codes à connaître. 308 et 307 se comportent comme 301 et 302 mais garantissent que la méthode et le corps de la requête restent les mêmes, ce qui compte pour les formulaires et les API.

Chaque redirection coûte un aller-retour supplémentaire, et une chaîne de redirections (A vers B vers C) en ajoute un par étape. Une boucle de redirections, où la destination ramène au départ, n’atteint jamais de page, et les navigateurs finissent par s’arrêter avec une erreur.

4xx : erreurs du client

• 401 Unauthorized. La requête n’a pas d’identifiants valides. Malgré son nom, cela veut dire « non authentifié » : connectez-vous, ou envoyez des identifiants valides, et réessayez.
• 403 Forbidden. Le serveur a compris la requête et la refuse. Le client est peut-être connu, mais n’est pas autorisé, et se reconnecter n’y changera rien.
• 404 Not Found. Il n’y a rien à cette adresse. Un serveur peut aussi renvoyer 404 pour cacher une page aux personnes qui n’ont pas le droit de la voir.
• 429 Too Many Requests. Le client a envoyé trop de requêtes dans un laps de temps donné. La réponse peut inclure un en-tête Retry-After indiquant combien de temps attendre.

5xx : erreurs du serveur

• 500 Internal Server Error. Une défaillance générale. Le serveur a rencontré quelque chose qu’il n’a pas pu gérer, souvent un bogue ou une mauvaise configuration.
• 502 Bad Gateway. Un serveur faisant office de passerelle ou de proxy a reçu une réponse invalide du serveur situé derrière lui.
• 503 Service Unavailable. Le serveur ne peut pas traiter la requête pour le moment, par exemple à cause d’une maintenance ou d’une surcharge. Il est prévu pour les situations temporaires et peut porter un en-tête Retry-After.
• 504 Gateway Timeout. Une passerelle ou un proxy a attendu trop longtemps le serveur situé derrière lui.

Pour lire les pannes, 502, 503 et 504 signalent généralement un problème entre des couches : le proxy en frontal fonctionne, et ce vers quoi il transmet ne fonctionne pas.

Pourquoi les codes d’état comptent pour la surveillance

Un code d’état est la vérification la plus rapide pour savoir qu’un site répond, et répond correctement. Il distingue des problèmes différents qui se ressemblent pour un visiteur :

• Aucun code (délai d’attente dépassé, connexion refusée, erreur DNS) : le serveur n’a pas pu être joint.
• 5xx : le serveur a été joint et a échoué.
• 4xx sur une page qui devrait fonctionner : une page manquante, un problème de droits, ou un blocage visant celui qui demande.
• 3xx là où vous attendiez 200 : une redirection qui a pu être ajoutée, retirée ou cassée.

Suivre les codes dans le temps révèle aussi des tendances. Un seul 503 pendant un déploiement n’est pas la même chose qu’un 503 chaque nuit à la même heure.

Les redirections dans la surveillance

Une vérification qui demande une adresse a besoin d’une règle pour les redirections. Considérer un 301 comme un échec ferait paraître cassé tout site qui redirige http vers https ou example.com vers www.example.com. La plupart des outils suivent donc les redirections et jugent la réponse finale, avec une limite au nombre de sauts suivis pour qu’une boucle ne tourne pas indéfiniment.

Comment UptimeWire juge une réponse

UptimeWire envoie une requête GET à l’adresse que vous avez configurée et suit les redirections, jusqu’à cinq. Il regarde ensuite la réponse finale :

• De 200 à 399, c’est disponible. Cela inclut les codes de succès 2xx et les réponses 3xx qui ne vont pas plus loin.
• Tout le reste est un échec. Cela inclut 404, 429, 500, 502, 503 et 504.
• 401 et 403 sont aussi des échecs. Une page surveillée qui demande une connexion, ou qui bloque la requête, est signalée comme échouée plutôt que traitée comme saine. Si vous surveillez une page derrière une authentification, choisissez une adresse publique, comme une page de santé.
• Plus de cinq redirections, c’est un échec, tout comme l’absence de réponse, une erreur de connexion, une panne DNS ou un certificat invalide.

Un succès sur le réseau n’est pas une application saine

Un 200 veut dire que le serveur a répondu avec succès. Cela ne veut pas dire que la page est correcte. Un paiement cassé qui affiche pourtant une page normale, une page vide là où il devrait y avoir des données, ou un message d’erreur dans le corps d’une réponse « 200 » passent tous une vérification HTTP. Voir temps d’arrêt pour ce qu’une telle vérification peut et ne peut pas voir. UptimeWire n’exécute pas de tests complets dans un navigateur. Il vérifie la réponse à une requête.

Diagnostic par code

Quand un code apparaît, regardez aussi le temps de réponse. Une hausse du temps de réponse survient souvent juste avant le début des erreurs 504 ou 503.