Recherche Codes HTTP Status

Codes HTTP Status — Référence Complète de 100 à 511

Chaque réponse HTTP d'un serveur inclut un code à trois chiffres qui indique au client ce qui s'est passé. Les codes sont groupés en cinq catégories : 1xx (informationnel), 2xx (succès), 3xx (redirection), 4xx (erreur client), et 5xx (erreur serveur). Cette référence liste les 60+ codes enregistrés avec noms, descriptions, cas d'usage courants et liens vers les RFC qui les définissent. Chaque carte porte aussi des badges d'ingénierie — Cacheable (selon l'ensemble cacheable heuristique du RFC 9111), Ré-essayable (sûr à réessayer avec backoff), Garde la méthode et Transmet le SEO — pour que les ingénieurs d'astreinte qui écrivent des couches de retry, de cache ou de redirection sachent d'un coup d'œil si un code est sûr à réessayer ou à cacher. Filtrez par catégorie ou par Cacheable/Ré-essayable, cherchez par numéro ou mot-clé en pensant aux flux curl/Postman/observabilité, et consultez les conseils sur Retry-After, X-RateLimit et RFC 7807 Problem Details dans la FAQ.

Que sont les codes de statut HTTP et comment sont-ils organisés?

Les codes de statut HTTP sont des nombres à trois chiffres retournés par un serveur en réponse à la requête d'un client, définis principalement dans RFC 9110 (HTTP Semantics, 2022) qui a remplacé RFC 7231. Ils sont regroupés en cinq classes par le premier chiffre: 1xx informationnel (requête reçue, en cours), 2xx succès (requête reçue, comprise et acceptée avec succès), 3xx redirection (action supplémentaire requise pour compléter la requête), 4xx erreur client (la requête contient une syntaxe erronée ou ne peut être satisfaite) et 5xx erreur serveur (le serveur a échoué à satisfaire une requête valide). Le registre complet est maintenu par l'IANA, et inclut actuellement environ 70 codes. Les clients devraient traiter les codes inconnus comme le x00 générique de leur classe — ainsi un nouveau code 499 devrait être traité comme 400 par un client qui ne le reconnaît pas.

Quelle est la différence entre 401 Unauthorized et 403 Forbidden?

Ceux-ci sont régulièrement confondus. 401 Unauthorized signifie "vous ne vous êtes pas authentifié — fournissez des identifiants." La réponse doit inclure un en-tête WWW-Authenticate indiquant au client quel schéma d'auth utiliser (Basic, Bearer, Digest). La même requête avec des identifiants valides réussirait. 403 Forbidden signifie "je sais qui vous êtes, et vous n'avez pas le droit." Se ré-authentifier ne servira à rien; les identifiants sont reconnus mais manquent de permission pour cette ressource. Le nom 401 est historiquement trompeur — "unauthorized" devrait vraiment être "unauthenticated." En pratique, de nombreuses APIs retournent 401 à tort pour les erreurs de permission. RFC 9110 indique explicitement que 403 doit être utilisé quand le serveur a compris la requête mais refuse de l'autoriser. Un code lié subtil est 407 Proxy Authentication Required, identique à 401 mais pour un serveur proxy dans la chaîne.

Quand utiliser les redirections 301 vs 302 vs 307 vs 308?

Les quatre redirigent, mais diffèrent sur deux dimensions: permanent vs temporaire, et si la méthode de requête peut changer. 301 Moved Permanently et 308 Permanent Redirect signalent tous deux que la ressource a déménagé définitivement — les moteurs de recherche transfèrent l'équité des liens. 302 Found et 307 Temporary Redirect signalent un déplacement temporaire. La différence de préservation de méthode est critique: 301 et 302 permettent historiquement aux clients de changer POST en GET lors de la redirection (par ambiguïté de conformité RFC), tandis que 307 et 308 exigent strictement la même méthode et le même corps. Pour les migrations SEO, utilisez 301. Pour les endpoints POST qui déménagent, utilisez 308 pour préserver le corps. Pour l'équilibrage de charge ou les tests A/B, utilisez 302 ou 307. Bing et Google ont déclaré explicitement que 308 est traité équivalemment à 301 pour le ranking.

Que signifie 429 Too Many Requests et comment le gérer?

429 (RFC 6585) signifie que le client a envoyé trop de requêtes dans un temps donné et est limité en débit. La réponse doit inclure un en-tête Retry-After — soit un entier delta-secondes ("Retry-After: 60") soit une HTTP-date — indiquant au client quand réessayer. Les clients bien élevés doivent implémenter un retour arrière exponentiel avec gigue: ne réessayez pas exactement à l'heure Retry-After (chaque client frapperait en même temps), réessayez plutôt entre Retry-After et Retry-After + gigue aléatoire. En-têtes supplémentaires couramment vus mais pas dans la RFC: X-RateLimit-Limit (le plafond), X-RateLimit-Remaining (appels restants dans la fenêtre actuelle), X-RateLimit-Reset (timestamp Unix de réinitialisation de la fenêtre). Le brouillon IETF draft-ietf-httpapi-ratelimit-headers propose des en-têtes standardisés RateLimit et RateLimit-Policy. De nombreuses APIs retournent aussi 503 avec Retry-After dans le même but; le signal clé est Retry-After.

Qu'est-ce que 418 I'm a teapot et est-il réel?

418 I'm a teapot est l'easter egg le plus célèbre dans HTTP. Il provient de RFC 2324 (Hyper Text Coffee Pot Control Protocol), une blague de poisson d'avril publiée le 1er avril 1998. Le sens prévu était qu'une théière, quand on lui demande d'infuser du café, doit répondre avec ce statut. Il ne fait pas partie de la spécification HTTP réelle (RFC 9110 ne l'inclut pas), et l'IANA ne l'enregistre pas. Cependant, de nombreux frameworks web et bibliothèques (Node.js, Go, Python, Rust) livrent des constantes pour HTTP 418 car les développeurs l'utilisent réellement pour des endpoints fantaisistes ou cachés. Le robots.txt de Google a retourné 418 pendant des années pour certains user agents. Réservez 418 pour les blagues et les pots de miel — ne l'utilisez jamais pour une sémantique d'erreur réelle, car les clients ne sont explicitement pas tenus de le gérer.

Quelle est la différence entre 500, 502, 503 et 504?

Les quatre sont des erreurs côté serveur mais indiquent différents modes de défaillance. 500 Internal Server Error est le fourre-tout générique quand une exception inattendue s'est produite dans le code de l'application — un NullPointerException, un rejet de promesse non géré, une requête de base de données qui a explosé. 502 Bad Gateway signifie qu'un serveur amont a retourné une réponse invalide à une passerelle/proxy (comme NGINX parlant à un backend mal élevé). 503 Service Unavailable signifie que le serveur est temporairement surchargé ou en maintenance et rejette intentionnellement les requêtes; devrait inclure Retry-After. 504 Gateway Timeout signifie qu'une passerelle/proxy a attendu un serveur amont et a expiré avant d'obtenir une réponse. La distinction importe pour ops: 500 signifie "corriger le code," 502 signifie "vérifier le service backend," 503 signifie "monter en échelle," et 504 signifie "vérifier les timeouts réseau/amont." Cloudflare ajoute des codes non standard 520-527 pour des défaillances en bordure plus granulaires.

Que signifie 422 Unprocessable Entity vs 400 Bad Request?

400 Bad Request signifie que la syntaxe est mauvaise: JSON malformé, en-têtes obligatoires manquants, format de query string invalide — le serveur ne peut même pas analyser ce que vous avez envoyé. 422 Unprocessable Entity (originalement de WebDAV RFC 4918, popularisé par les APIs REST) signifie que la syntaxe est correcte mais la sémantique est mauvaise: le JSON s'analyse proprement, mais "email" n'est pas une adresse e-mail valide, ou "age" est -5, ou "endDate" est avant "startDate". RFC 9110 réaffirme 422 pour l'audience HTTP plus large. La plupart des APIs REST modernes (Stripe, GitHub, Rails) utilisent 422 pour les erreurs de validation, ce qui permet aux clients de distinguer "mon code a généré du JSON invalide" de "mon code a généré du JSON valide avec des valeurs invalides." Associez 422 à un corps JSON listant les erreurs au niveau des champs (RFC 7807 Problem Details est le format standard). 409 Conflict est un code lié pour les conflits d'état comme la création de ressource dupliquée.

Quels sont les codes de statut moins connus que je devrais connaître?

Au-delà des courants, plusieurs codes de niche résolvent de vrais problèmes. 100 Continue est utilisé avec Expect: 100-continue pour éviter d'envoyer un corps volumineux si le serveur va le rejeter. 103 Early Hints (RFC 8297) permet aux serveurs d'envoyer des en-têtes Link avant la réponse finale, permettant le préchargement par le navigateur. 226 IM Used est pour l'encodage delta (rare). 308 Permanent Redirect est le 301 préservant la méthode. 410 Gone signale qu'une ressource a été délibérément supprimée et est peu susceptible de revenir — plus fort que 404 et bon pour le désindexage SEO. 451 Unavailable For Legal Reasons (RFC 7725, nommé d'après Fahrenheit 451) est utilisé pour la suppression de contenu ordonnée par tribunal. 425 Too Early empêche les attaques par rejeu dans TLS 1.3 0-RTT. 428 Precondition Required force les clients à utiliser If-Match pour les requêtes conditionnelles. 511 Network Authentication Required est ce que les portails captifs devraient retourner. Les connaître vous permet de communiquer l'intention avec précision.

Quels codes HTTP sont cacheables par défaut?

Le RFC 9111 (HTTP Caching) définit un ensemble spécifique de réponses heuristiquement cacheables par défaut — c'est-à-dire qu'un cache partagé peut les stocker même sans en-tête Cache-Control ou Expires explicite. Cet ensemble est : 200 OK, 203 Non-Authoritative Information, 204 No Content, 206 Partial Content, 300 Multiple Choices, 301 Moved Permanently, 308 Permanent Redirect, 404 Not Found, 405 Method Not Allowed, 410 Gone, 414 URI Too Long et 451 Unavailable For Legal Reasons. L'outil marque chacun d'un badge Cacheable, et le filtre Cacheable seulement réduit la grille exactement à cette liste. Trois réserves : (1) c'est le comportement par défaut — toute réponse peut être rendue cacheable ou non avec des directives Cache-Control explicites ; (2) les réponses avec no-store, private ou un en-tête Vary: * ne sont jamais stockées ; et (3) les erreurs comme 404 et 410 ne sont cachées que brièvement via la fraîcheur heuristique (typiquement une fraction du temps depuis Last-Modified). En cas de doute, définissez Cache-Control explicitement plutôt que de vous fier à l'ensemble heuristique.

Quels codes 4xx et 5xx peut-on réessayer automatiquement en toute sécurité?

La sûreté du retry dépend de l'idempotence de la requête et du caractère transitoire de l'échec. Les codes qui valent la peine d'être réessayés automatiquement — toujours avec un backoff exponentiel et du jitter, et en honorant tout en-tête Retry-After — sont : 408 Request Timeout, 425 Too Early, 429 Too Many Requests, 500 Internal Server Error (uniquement pour les méthodes idempotentes comme GET/PUT/DELETE), 502 Bad Gateway, 503 Service Unavailable et 504 Gateway Timeout. L'outil les marque d'un badge Ré-essayable et le filtre Ré-essayable seulement les isole. Ne réessayez jamais aveuglément 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 409 Conflict ou 422 Unprocessable Content — la requête elle-même est erronée et la réessayer à l'identique échouera de nouveau. Pour un 500 sur un POST non idempotent, réessayer risque de créer des doublons ; utilisez une clé d'idempotence (comme Stripe et la plupart des APIs de paiement) pour que le retry soit sûr. Pour 429 et 503, préférez le Retry-After fourni par le serveur à votre propre minuteur, et ajoutez du jitter pour qu'une flotte de clients ne réessaie pas en même temps (effet de troupeau) à l'instant où la fenêtre se réinitialise.

Caractéristiques Clés

• Chaque code HTTP status enregistré IANA (60+) couvrant 100 à 511
• Descriptions détaillées pour les 25 codes les plus courants (200, 301, 304, 401, 403, 404, 429, 500, 503, etc.)
• Recherche par numéro de code ou mot-clé à travers noms et descriptions
• Filtre par catégorie : 1xx Informationnel, 2xx Succès, 3xx Redirection, 4xx Erreur Client, 5xx Erreur Serveur
• Indicateurs de catégorie codés couleur pour reconnaissance visuelle instantanée
• Liens directs vers le RFC définissant pour chaque code (RFC 9110, RFC 6585, etc.)
• Boutons de saut rapide pour les quatre codes les plus recherchés (200, 301, 404, 500)
• Copiez n'importe quel code de status dans le presse-papiers en un clic pour rapports de bugs et documentation
• Exemples de cas d'usage expliquant quand chaque code est approprié
• Couvre les ajouts modernes : 103 Early Hints, 308 Permanent Redirect, 425 Too Early, 451 Legal
• Inclut 418 I'm a teapot de RFC 2324 pour l'exhaustivité
• JavaScript pur — aucune bibliothèque externe
• Fonctionne hors-ligne après le premier chargement
• Mise en page en grille responsive pour mobile et desktop
• 100% côté client — aucune requête n'est faite par la recherche