Codes de statut HTTP — Cloudflare, nginx, snippets

Que fait l’outil de codes de statut HTTP ?

L’outil est un catalogue de référence consultable pour les codes de statut HTTP. Il couvre la RFC 9110 intégralement — tous les codes 1xx informatifs, 2xx de succès, 3xx de redirection, 4xx d’erreur client et 5xx d’erreur serveur — et y ajoute les codes spécifiques aux plateformes que le registre IANA omet mais qui apparaissent chaque jour dans tes logs de production : Cloudflare 520-530, nginx 444 et 494-499, IIS 440 et 449, AWS Application Load Balancer 460/463 et CloudFront 561.

Pour chaque code l’outil affiche : la phrase canonique, une explication technique en deux à quatre phrases, les méthodes HTTP typiques (POST tend à renvoyer 201, GET tend à renvoyer 200), le lien vers la spécification (RFC, documentation Cloudflare, code source nginx) et un lien vers l’article Wikipedia pour le contexte éditorial.

Quels codes de plateforme l’outil couvre-t-il ?

MDN documente uniquement le standard enregistré par l’IANA. Les outils présents dans ta pile de production émettent pourtant régulièrement des codes non standard :

• Cloudflare 520-527 et 530 — la famille complète « le edge n’a pas pu joindre l’origine ». 521 (origine hors ligne), 522 (timeout de connexion), 523 (erreur DNS d’origine), 524 (réponse d’origine > 100 s), 525 et 526 (problèmes SSL côté origine), 527 (erreur Railgun), 530 (wrapper pour les erreurs de la série 1xxx).
• nginx 444 et 494-499 — codes internes du code source nginx : 444 (connexion fermée silencieusement), 494 (en-tête trop volumineux), 495 et 496 (problèmes de certificat client), 497 (requête HTTP sur un port HTTPS), 499 (le client a fermé la connexion).
• IIS 440 et 449 — codes spécifiques à Microsoft : 440 (timeout de connexion), 449 (Retry With).
• AWS Application Load Balancer 460/463 et CloudFront 561 — codes edge des fournisseurs cloud pour timeout client, chaîne X-Forwarded-For surdimensionnée et échec d’authentification Lambda@Edge.

Le filtre « codes de plateforme uniquement » masque le standard RFC et n’affiche que ce monde — utile quand tu enquêtes sur un incident 5xx précis dans le tableau de bord Cloudflare.

Que sont les fiches comparatives ?

Quatre paires de codes sont les plus confondues en 2026 — l’outil affiche automatiquement une fiche comparative dès que tu sélectionnes l’un d’entre eux :

• 401 vs 403 — authentification (pas de login) vs autorisation (connecté mais sans permission).
• 301 vs 302 vs 307 vs 308 — permanence × préservation de la méthode, présentées comme table de vérité. 308 = permanent + préservant la méthode, le choix moderne.
• 400 vs 422 — erreur de couche HTTP (syntaxe, framing) vs erreur de règle métier (validation, conflit). Utilise 422 quand le JSON est syntaxiquement correct mais que le champ e-mail est invalide.
• 502 vs 503 vs 504 — upstream cassé vs origine surchargée vs upstream silencieux. Les trois erreurs de passerelle se ressemblent mais ont des diagnostics de cause racine distincts.

Chaque groupe contient un résumé d’une ou deux phrases et des boutons vers les codes voisins — accès direct sans changement d’URL.

Comment fonctionne le filtre par méthode HTTP ?

Chaque code de la base porte une liste de « méthodes HTTP typiques qui produisent ce code ». Le filtre par méthode réduit la liste à une seule méthode : clique « POST » et tu ne vois que les codes qui ont du sens après un POST — 200, 201, 202, 204, 303, 307, 400, 409, 422, 429, 500. Clique « GET » et tu vois les codes typiques d’un GET — 200, 206, 301, 304, 404, 410.

C’est la vue inverse de la carte de détail : là, chaque code dit « ces méthodes me déclenchent » ; le filtre dit « cette méthode me renvoie les codes suivants ».

Quels langages de snippet l’export prend-il en charge ?

Six langages cibles, tous générés côté client :

• Enum TypeScript — export enum HttpStatus { NOT_FOUND = 404, … } avec commentaires JSDoc.
• Dict Python — HTTP_STATUS_CODES = { 404: "Not Found", … } comme table de correspondance.
• Bloc const Go — const ( StatusNot_Found = 404 … ) dans le style idiomatique de Go.
• Enum Rust — #[repr(u16)] pub enum HttpStatus { Not_Found = 404, … } avec représentation u16.
• Record Java — public record HttpStatus(int code, String name) plus des constantes static final.
• Module Ruby — module HttpStatus NOT_FOUND = 404 … end comme conteneur de constantes.

Par défaut l’export émet tous les codes — standard plus codes de plateforme. Tu peux restreindre la sélection avec le sélecteur « standard RFC uniquement » ; le monde des plateformes disparaît alors du code généré. Les snippets sont commentés proprement et peuvent être intégrés à une base de code tels quels — sans tests, sans dépendances, sans avertissements du compilateur.

Pourquoi cet outil tourne-t-il intégralement côté client, sans tracking ?

Cet outil n’envoie aucune requête à un serveur. La base complète des codes de statut est intégrée dans le bundle JavaScript, la recherche s’exécute via String.prototype.toLowerCase et includes, la génération de snippets via des template strings. Pas d’appel d’API, pas de télémétrie, pas de cookie, pas de localStorage.

Plus de détails dans la OWASP Logging Cheat Sheet sur ce qu’une recherche dans un outil expose réellement — et pourquoi, pour des requêtes à enjeu de sécurité (recherche de code de statut pendant un incident), il est important que la recherche ne finisse pas dans le log d’un tiers. Le registre IANA des codes de statut HTTP est la source canonique pour les codes enregistrés par l’IANA ; tout le reste provient directement de la documentation des plateformes (erreurs 5xx Cloudflare, traitement des requêtes HTTP par nginx, codes de statut HTTP Microsoft IIS).