Recherchez n’importe quel code d’état HTTP : sa signification, les situations où les serveurs le renvoient et la spécification qui le définit. Effectuez une recherche par numéro ou mot-clé, filtrez par classe et créez un lien direct vers un code.
Le serveur a reçu les en-têtes de la requête et le client peut envoyer le corps. Apparaît lorsqu’un client envoie « Expect: 100-continue » avant de téléverser un corps volumineux.
Le serveur a accepté une requête WebDAV, mais ne l’a pas encore terminée. Ce code a été retiré des spécifications WebDAV ultérieures et est rarement utilisé aujourd’hui.
Envoyé avant la réponse finale pour permettre au navigateur de commencer le préchargement des ressources indiquées dans les en-têtes Link. Utilisé par les CDN et les serveurs pour accélérer le chargement des pages.
La requête a abouti et créé une nouvelle ressource, généralement identifiée par l’en-tête Location. Réponse fréquente après une requête POST qui crée un enregistrement.
La requête a été acceptée pour traitement, mais celui-ci n’est pas terminé. Utilisé par les API qui mettent des tâches en file d’attente, comme les exports ou les traitements par lots.
La requête a abouti et il n’y a aucun contenu à renvoyer. Fréquent pour les requêtes DELETE et lors de l’enregistrement de données quand le client n’a pas besoin du corps de la réponse.
Le serveur renvoie uniquement la plage d’octets demandée par le client. Apparaît lors de la diffusion de vidéos, de la reprise de téléchargements ou lorsqu’un client envoie un en-tête Range.
La ressource a été déplacée définitivement vers l’URL indiquée dans l’en-tête Location. Les navigateurs et les moteurs de recherche mettent à jour leurs liens ; certains clients remplacent POST par GET lorsqu’ils suivent la redirection.
La ressource se trouve temporairement à une autre URL, indiquée dans l’en-tête Location. Fréquent après une connexion et pour les redirections de courte durée ; les navigateurs utilisent généralement GET pour la suivre.
Le client doit récupérer le résultat à une autre URL avec GET. Utilisé après une requête POST de formulaire pour rediriger vers une page de confirmation (modèle Post/Redirect/Get).
La copie en cache est toujours valide ; le serveur n’envoie donc pas de corps de réponse. Apparaît lorsqu’un navigateur revalide un fichier en cache avec If-None-Match ou If-Modified-Since.
Demandait au client d’utiliser un proxy indiqué dans l’en-tête Location. Ce code est obsolète pour des raisons de sécurité et les navigateurs l’ignorent.
La ressource se trouve temporairement à une autre URL et le client doit répéter la requête avec la même méthode et le même corps. Les navigateurs l’utilisent aussi pour les redirections internes HSTS vers HTTPS.
La ressource a été déplacée définitivement et le client doit utiliser la même méthode et le même corps à la nouvelle URL. C’est l’équivalent permanent du code 307, adapté aux redirections de requêtes POST.
La requête ne contient pas d’identifiants d’authentification valides. Malgré son nom, ce code signifie « non authentifié » ; le serveur envoie un en-tête WWW-Authenticate qui indique comment se connecter.
Réservé à un usage futur dans la spécification HTTP. Certaines API et certains services de paiement l’utilisent lorsqu’un paiement ou un abonnement est requis.
Le serveur a compris la requête, mais la refuse ; se reconnecter n’y changera rien. Ce code apparaît notamment lorsque les autorisations sont insuffisantes, que l’affichage du contenu d’un répertoire est désactivé ou qu’un pare-feu bloque le client.
Le serveur ne trouve pas la ressource demandée. Il s’agit généralement d’un lien mal saisi ou obsolète, d’une page supprimée ou d’une route d’API incorrecte.
La ressource existe, mais ne prend pas en charge la méthode HTTP utilisée, par exemple une requête POST vers une URL en lecture seule. La réponse indique les méthodes autorisées dans l’en-tête Allow.
Comme pour le code 401, mais le client doit d’abord s’authentifier auprès d’un proxy. Ce code apparaît sur les réseaux d’entreprise qui utilisent un proxy avec authentification.
Le serveur a expiré le délai d’attente pendant que le client terminait l’envoi de la requête. Ce code apparaît en cas de connexion lente ou interrompue.
La requête entre en conflit avec l’état actuel de la ressource, par exemple en cas de conflit de modification ou lors de la création d’un élément qui existe déjà.
La ressource a été supprimée définitivement et ne sera pas rétablie. Contrairement au code 404, ce code indique aux moteurs de recherche de supprimer l’URL plus rapidement.
Une condition indiquée dans les en-têtes de la requête, comme If-Match, n’a pas été remplie. Ce code permet d’éviter d’écraser une ressource modifiée depuis sa dernière consultation par le client.
Le corps de la requête dépasse la taille acceptée par le serveur. Ce code apparaît notamment lors de l’envoi d’un fichier dépassant une limite telle que client_max_body_size dans nginx.
L’URL est trop longue pour être traitée par le serveur. Cela est généralement dû à un formulaire qui envoie trop de données avec GET ou à une boucle de redirection qui ajoute sans cesse des paramètres.
Le serveur ne prend pas en charge le format du corps de la requête, par exemple si vous envoyez du XML à un point de terminaison qui attend application/json.
Une blague du poisson d’avril de 1998, tirée du protocole Hyper Text Coffee Pot Control Protocol : une théière qui refuse de faire du café. HTTP réserve ce code comme inutilisé, mais certains serveurs le renvoient comme clin d’œil ou pour rejeter des robots indésirables.
Ce code n’est pas standard. Laravel le renvoie lorsque le jeton CSRF d’un formulaire est absent ou a expiré, généralement après l’expiration d’une session.
La requête a atteint un serveur qui ne peut pas produire de réponse pour cet hôte, par exemple lorsqu’une connexion HTTP/2 est réutilisée pour un autre domaine.
La requête est bien formée, mais son contenu est invalide, par exemple un formulaire qui ne satisfait pas aux règles de validation. Les API l’utilisent largement pour signaler des erreurs de validation.
Le client a envoyé trop de requêtes dans un intervalle donné. Les API l’utilisent pour limiter le débit et incluent souvent un en-tête Retry-After indiquant quand réessayer.
Les en-têtes de la requête sont trop volumineux, souvent à cause de cookies trop nombreux ou trop volumineux. Effacer les cookies du site résout généralement le problème.
Ce code n’est pas standard. nginx l’utilise en interne pour fermer la connexion sans envoyer de réponse, souvent afin d’écarter du trafic indésirable ; les clients ne le reçoivent jamais.
La ressource est indisponible pour des raisons juridiques, comme une décision de justice ou la censure d’un gouvernement. Le nombre fait référence au roman Fahrenheit 451.
Ce code n’est pas standard. Il s’agit de la variante de 431 propre à nginx, enregistrée lorsque les en-têtes de la requête dépassent la capacité de ses tampons.
Ce code n’est pas standard. nginx l’enregistre lorsque le client ferme la connexion avant que le serveur ne réponde, par exemple si un utilisateur annule le chargement d’une page lente ou si le délai d’attente côté client expire.
Le serveur a rencontré une erreur inattendue et n’a pas pu traiter la requête. Cette erreur générique peut être due à un bogue, à un plantage ou à une mauvaise configuration ; les détails figurent dans les journaux du serveur.
Une passerelle ou un proxy a reçu une réponse invalide du serveur en amont. Ce code apparaît souvent lorsque l’application derrière nginx ou un répartiteur de charge a planté ou redémarre.
Le serveur ne peut temporairement pas traiter la requête, car il est surchargé ou en maintenance. Un en-tête Retry-After peut indiquer quand réessayer.
Une passerelle ou un proxy n’a pas reçu de réponse du serveur en amont à temps. Ce code apparaît lorsqu’une requête backend est trop lente, par exemple à cause d’une longue requête à la base de données.
Le client doit s’authentifier pour accéder au réseau. Ce code est envoyé par les portails captifs des réseaux Wi-Fi d’hôtels, d’aéroports ou de cafés avant la connexion.
Code non standard. Cloudflare le renvoie lorsque le serveur d’origine a refusé la connexion, généralement parce que le serveur Web est hors service ou bloque les adresses IP de Cloudflare.
Code non standard. Cloudflare le renvoie lorsqu’il ne parvient pas à joindre le serveur d’origine, par exemple en raison d’un problème de DNS ou de routage.
Code non standard. Cloudflare le renvoie lorsqu’il s’est connecté au serveur d’origine, mais n’a pas reçu de réponse HTTP avant l’expiration du délai (100 secondes par défaut).
Code non standard. Cloudflare le renvoie lorsque le certificat SSL du serveur d’origine n’est pas valide et que le mode SSL Full (strict) est activé.
Défini dans Cloudflare
Mode d’emploi
Saisissez un numéro de code (par exemple 404 ou simplement 5 pour toutes les erreurs serveur) ou un mot-clé comme « redirection » ou « délai d’attente ».
Affinez la liste avec le filtre par classe : information, succès, redirection, erreur client ou erreur serveur.
Utilisez « Copier le lien » sur un code pour partager un lien direct vers celui-ci, par exemple dans un rapport de bogue.
Fonctionnement
Chaque réponse HTTP commence par un code d’état à trois chiffres. Le premier chiffre indique la classe : réponses informatives 1xx, succès 2xx, redirections 3xx, erreurs causées par la requête 4xx et erreurs côté serveur 5xx. Les clients qui ne reconnaissent pas un code précis le traitent comme le code x00 de sa classe : un code 4xx inconnu est donc traité comme 400.
Les codes principaux sont définis dans la RFC 9110 (sémantique HTTP, 2022), qui a remplacé l’ancienne RFC 7231. D’autres proviennent d’extensions : WebDAV (RFC 4918), RFC 6585 pour 428, 429, 431 et 511, RFC 7725 pour 451, et RFC 8470 pour 425. La RFC 9110 a également renommé deux codes : 413 s’appelle désormais « Content Too Large » et 422 « Unprocessable Content ». Vous pouvez encore les voir sous leurs anciens noms, « Payload Too Large » et « Unprocessable Entity ».
Certains codes présents dans les journaux ne sont pas des normes. nginx utilise en interne 444 et 494–499 (499 indique qu’un client a cessé d’attendre), et Cloudflare renvoie 520–526 lorsqu’il ne parvient pas à obtenir une réponse correcte du serveur d’origine. Ils sont indiqués comme « Non-standard » dans la liste. Les libellés de motif (comme « Not Found ») sont affichés en anglais, tels qu’ils figurent dans les spécifications ; HTTP/2 et HTTP/3 n’envoient que le numéro.
Exemples
301 ou 308 pour déplacer un site
Les deux redirections sont permanentes. Utilisez 301 pour les déplacements de page ordinaires ; utilisez 308 lorsque les clients doivent répéter les requêtes POST ou PUT vers la nouvelle URL, car certains clients transforment POST en GET après une réponse 301.
401 ou 403
Une API renvoie 401 lorsqu’aucun jeton n’est fourni ou que le jeton a expiré : le client doit alors se connecter. Elle renvoie 403 lorsque le jeton est valide, mais que l’utilisateur n’a pas les autorisations nécessaires ; se reconnecter ne changera rien.
Diagnostiquer une erreur 502 derrière nginx
Une réponse 502 Bad Gateway de nginx signifie que l’application en arrière-plan n’a pas répondu correctement. Vérifiez que le processus de l’application est en cours d’exécution et consultez ses journaux ; une réponse 504 signifie plutôt qu’elle a mis trop de temps à répondre.
Foire aux questions
Quelle est la différence entre 404 et 410 ?
404 signifie que le serveur ne trouve pas la ressource, sans rien indiquer sur son avenir. 410 signifie que la ressource a été supprimée volontairement et ne sera pas rétablie, ce qui aide les moteurs de recherche à retirer l’URL plus rapidement.
Une erreur de validation doit-elle renvoyer le code 400 ou 422 ?
Les deux sont utilisés. Le code 400 convient aux requêtes que le serveur ne peut pas analyser, par exemple un JSON mal formé. Le code 422 convient aux requêtes correctement analysées, mais qui contiennent des valeurs non valides, comme une adresse e-mail sans @.
Le code 418 « I'm a teapot » est-il un véritable code d’état ?
Ce code vient d’une RFC publiée pour le poisson d’avril en 1998. La RFC 9110 réserve le code 418 pour qu’il ne soit attribué à rien d’autre. Quelques serveurs le renvoient comme une plaisanterie, mais il n’a pas de signification standard.
D’où vient le code 499 ?
Le code 499 est spécifique à nginx. Il apparaît dans les journaux nginx lorsque le client ferme la connexion avant que le serveur n’envoie une réponse. Le client ne reçoit jamais le code 499 ; il indique généralement des réponses lentes ou des délais d’attente côté client.
Les moteurs de recherche traitent-ils une redirection 302 comme une 301 ?
Une redirection 302 indique un déplacement temporaire. Les moteurs de recherche conservent donc généralement l’URL d’origine dans leur index au début. Si une redirection 302 reste en place longtemps, Google peut la traiter comme une redirection permanente. Utilisez 301 ou 308 pour les déplacements permanents.
Confidentialité
La liste est intégrée à la page. La recherche et le filtrage s’effectuent dans votre navigateur ; vos termes de recherche ne sont ni envoyés ailleurs ni inclus dans les statistiques d’audience.