Référence des codes de statut HTTP

La Référence des codes de statut HTTP est un index complet et consultable de chaque code de statut défini dans les spécifications HTTP — de 100 Continue jusqu'à 511 Network Authentication Required. Chaque entrée indique le nom canonique, la RFC qui le définit, ce que le code signifie réellement, quand l'envoyer, quand ne pas l'envoyer et les pièges courants qui affectent les bases de code réelles. Un filtre en direct et des puces de catégorie vous permettent de passer d'une classe à l'autre en un seul clic.

Contrairement à un simple antisèche, cet outil donne à chaque code sa propre micro-page avec trois panneaux codés par couleur (à faire / à éviter / pièges) et des gestionnaires prêts à être collés pour Express.js, Django, FastAPI et Go net/http. Le diagramme filaire animé montre le trajet de la requête du client vers le serveur et le retour du statut choisi — utile pour les débutants qui apprennent ce qu'un code de statut représente réellement sur le réseau.

Pourquoi une référence des codes de statut est importante

Comment utiliser la Référence des codes de statut HTTP

1. Recherche rapide. Saisissez un code (404) ou un fragment de nom (teapot, gateway) dans le champ de recherche en haut et validez. L'entrée correspondante s'ouvre avec le panneau de détails complet.
2. Parcourir par classe. Cliquez sur l'une des 5 puces (1xx, 2xx, 3xx, 4xx, 5xx) pour filtrer la grille sur cette classe. Cliquez sur Tout pour réinitialiser.
3. Filtre en direct. Le champ de filtre juste au-dessus de la grille affine les cartes à mesure que vous saisissez — utile lorsque vous vous souvenez de la moitié d'un nom comme too many ou precondition.
4. Inspecter un code. Cliquez sur n'importe quelle carte pour ouvrir son panneau de détails. Vous verrez la signification, quand l'utiliser, quand ne pas l'utiliser, les pièges courants et un bloc d'extraits pour 4 frameworks.
5. Copier un extrait. Utilisez le sélecteur d'onglet et le petit bouton Copier pour récupérer un gestionnaire prêt à être collé.
6. Comparer les voisins. Le panneau de détails se termine par des cartes sœurs de la même classe (1xx / 2xx / 3xx / 4xx / 5xx) pour une comparaison rapide côte à côte.

Les cinq classes de statuts HTTP en un coup d'œil

Paires fréquemment confondues

• 401 vs 403. 401 signifie non authentifié — la requête manque d'identifiants valides. 403 signifie authentifié mais non autorisé — les identifiants sont corrects mais l'utilisateur ne dispose pas des permissions nécessaires.
• 404 vs 410. 404 signifie inconnu : peut-être qu'il existe quelque part, peut-être une faute de frappe. 410 signifie délibérément supprimé : les moteurs de recherche doivent le retirer de l'index.
• 301 vs 302 vs 307 vs 308. 301 / 308 sont permanents (308 préserve strictement la méthode et le corps), 302 / 307 sont temporaires (307 préserve strictement la méthode et le corps). Utilisez 307 / 308 pour les redirections POST / PUT / PATCH.
• 400 vs 422. 400 signifie que le corps de la requête est malformé (mauvais JSON, champ manquant). 422 signifie que le corps a été analysé correctement mais que les valeurs ne respectent pas les règles de gestion (format d'e-mail invalide, quantité hors limite).
• 502 vs 503 vs 504. 502 signifie que le serveur amont a envoyé des données incorrectes. 503 signifie que le serveur est surchargé ou en maintenance. 504 signifie que le serveur amont n'a pas répondu à temps.
• 409 vs 412. 409 est un conflit avec l'état actuel de la ressource. 412 signifie spécifiquement qu'un en-tête de précondition (If-Match, If-Unmodified-Since) a été évalué à faux.

En-têtes associés à des codes de statut spécifiques

• 201 Created — devrait inclure Location pointant vers la nouvelle ressource.
• 301 / 302 / 307 / 308 — doivent inclure Location avec l'URL cible.
• 304 Not Modified — doit répéter les en-têtes qui seraient apparus sur un 200 (ETag, Cache-Control, Vary).
• 401 Unauthorized — doit inclure WWW-Authenticate listant les schémas acceptés (Basic, Bearer).
• 405 Method Not Allowed — doit inclure Allow listant les méthodes qui sont autorisées.
• 413 / 429 / 503 — incluent souvent Retry-After (secondes ou date-HTTP) pour que les clients ralentissent correctement.
• 416 Range Not Satisfiable — doit inclure Content-Range: bytes */<length>.

Codes de statut que vous pouvez presque toujours ignorer

Une poignée de codes sont techniquement valides mais extrêmement rares dans les API modernes : 305 Use Proxy (obsolète), 306 (réservé, inutilisé), 305, 506 Variant Also Negotiates, 510 Not Extended et 508 Loop Detected. La plupart sont conservés dans le registre pour des raisons historiques. Si votre bibliothèque ou middleware en émet un, considérez-le comme un rapport de bug contre la bibliothèque — et non comme une incitation à le gérer de manière particulière.

FAQ

L'outil inclut-il des codes provenant de RFC autres que la 9110 ?

Oui. Il couvre la RFC 9110 (sémantique HTTP), la RFC 6585 (4xx / 5xx supplémentaires), la RFC 4918 (WebDAV), la RFC 5842 (liaisons WebDAV), la RFC 7725 (451), la RFC 8297 (103 Early Hints), la RFC 8470 (425 Too Early) et la célèbre et ludique RFC 2324 (418 Teapot).

Ces codes sont-ils valides en HTTP/2 et HTTP/3 ?

Oui. La sémantique des codes de statut est définie dans la RFC 9110, qui est le document de sémantique HTTP indépendant de la version. HTTP/2 (RFC 9113) et HTTP/3 (RFC 9114) modifient uniquement le fractionnement (framing) et le transport.

Puis-je faire un lien directement vers un code spécifique ?

Soumettez le formulaire avec un seul code (par exemple 404) et le panneau de détails se chargera sous le formulaire. L'URL affiche votre recherche et peut être partagée en toute sécurité — son ouverture chargera le même résultat.

Pourquoi mon framework ne me permet-il pas de renvoyer 418 ?

Les anciennes versions de certaines bibliothèques HTTP refusent d'émettre des codes qui ne figurent pas dans leur registre interne. La solution consiste à mettre à niveau la bibliothèque ou, si possible, à écrire la ligne de statut manuellement.

Une API devrait-elle jamais renvoyer un 200 avec un corps d'erreur ?

Non. La supervision, les tentatives et les intermédiaires partent tous du principe que 2xx signifie un succès. Si vous devez renvoyer une structure d'erreur, renvoyez un 4xx ou 5xx approprié et insérez les détails structurés à l'intérieur du corps. Le format Problem Details for HTTP APIs (RFC 9457) est un bon modèle.

Existe-t-il un registre faisant autorité pour les codes de statut HTTP ?

Oui. L'IANA maintient le registre à l'adresse iana.org/assignments/http-status-codes. Cet outil reste synchronisé avec ce registre ainsi qu'avec les RFC les plus couramment citées.