Aller au contenu principal

Référence des codes HTTP — outil gratuit

Référence consultable pour tous les codes d'état HTTP — leur signification, leur contexte d'utilisation et les causes fréquentes. De 100 à 511.

Fonctionne hors ligne une fois chargé

61 codes de statut

100

Continuer

Le serveur a reçu les en-têtes de demande et le client doit procéder avec le corps.

Utilisé pour les demandes avec Expect: 100-continue. Le serveur reconnaît qu'il est prêt à recevoir le corps avant que le client ne l'envoie. Rarement vu dans les applications web modernes.

RFC 9110 ↗
101

Changement de protocoles

Le serveur change de protocole comme demandé par le client.

Généralement utilisé pour les mises à niveau WebSocket. Le client demande Upgrade: websocket et le serveur répond 101 pour basculer.

RFC 9110 ↗
102

Traitement

Le serveur a reçu la demande et la traite, mais aucune réponse n'est disponible pour l'instant.

Une réponse intermédiaire WebDAV envoyée pour éviter les délais d'attente du client pendant les opérations longues. Obsolète. Les serveurs modernes ne devraient pas l'envoyer.

RFC 2518 ↗
103

Indices préalables

En-têtes préliminaires envoyés avant la réponse finale.

Permet aux serveurs d'envoyer des en-têtes Link (préchargement/préconnexion) tandis que la réponse finale est encore en cours de préparation, afin que les navigateurs puissent commencer à récupérer les ressources critiques plus tôt.

RFC 8297 ↗
200

OK

La demande a réussi.

La réponse de succès standard. La signification dépend de la méthode HTTP : GET → ressource renvoyée, POST/PUT → action complétée.

RFC 9110 ↗
201

Créé

Une nouvelle ressource a été créée avec succès.

Courant après une requête POST. La réponse doit inclure un en-tête Location pointant vers l'URL de la nouvelle ressource.

RFC 9110 ↗
202

Accepté

La demande a été acceptée pour traitement, mais le traitement n'est pas terminé.

Pour les opérations asynchrones. Le serveur met le travail en file d'attente. Le client doit interroger un point de terminaison d'état ou revérifier plus tard.

RFC 9110 ↗
203

Information non-autorisée

La réponse a été modifiée par un proxy de transformation.

La demande a réussi, mais un intermédiaire (tel qu'un proxy de mise en cache ou de transformation) a modifié la charge utile du serveur d'origine. Par exemple, recompression d'images. Rare en pratique.

RFC 9110 ↗
204

Pas de contenu

La demande a réussi, mais il n'y a pas de corps de réponse.

Souvent utilisé pour les opérations DELETE ou les mises à jour PUT qui n'ont pas besoin de renvoyer un corps. Le client ne doit pas quitter la page actuelle.

RFC 9110 ↗
205

Réinitialiser le contenu

La demande a réussi. Le client doit réinitialiser la vue du document.

Comme 204, aucun corps n'est renvoyé. Mais le client est également invité à réinitialiser le formulaire ou la vue qui a produit la demande (par exemple, effacer les champs du formulaire pour la saisie suivante).

RFC 9110 ↗
206

Contenu partiel

Le serveur n'a livré qu'une partie de la ressource.

Réponse à une demande de plage (Range). Utilisé par les lecteurs vidéo et les gestionnaires de téléchargement pour reprendre les téléchargements interrompus ou diffuser de gros fichiers.

RFC 9110 ↗
207

Statuts multiples

Le corps de la réponse contient plusieurs codes d'état pour plusieurs opérations.

WebDAV : un corps XML rapporte le résultat de plusieurs sous-opérations indépendamment. Par exemple, un déplacement par lot où certains éléments ont réussi et d'autres ont échoué.

RFC 4918 ↗
208

Déjà signalé

Les membres d'une collection ont déjà été listés précédemment dans la réponse.

WebDAV : utilisé dans les réponses Multi-Status 207 pour éviter de lister à nouveau les membres de la même collection lorsque les liaisons créent des boucles.

RFC 5842 ↗
226

IM utilisé

La réponse est le résultat des manipulations d'instance appliquées à la ressource.

Codage Delta : le serveur renvoie une différence par rapport à une version antérieure au lieu de la ressource complète, ce qui économise de la bande passante. Très rarement implémenté.

RFC 3229 ↗
300

Choix multiples

Plusieurs représentations de la ressource sont disponibles.

Le serveur propose plusieurs options (par exemple, différents formats ou langues) et le client doit en choisir une. Rarement utilisé, car la négociation de contenu automatique gère généralement cela.

RFC 9110 ↗
301

Déplacé de façon permanente

La ressource a été déplacée de façon permanente vers une nouvelle URL.

À utiliser pour les changements d'URL permanents. Les moteurs de recherche mettront à jour leur index. L'autorité SEO est transférée à la nouvelle URL.

RFC 9110 ↗
302

Trouvé (redirection temporaire)

La ressource se trouve temporairement à une autre URL.

Indique que la redirection n'est pas permanente. La mise en cache est moins agressive qu'avec le 301. À utiliser pour des cas comme « connexion requise, redirection vers /login ».

RFC 9110 ↗
303

Voir autre

Redirection vers une autre URL avec GET.

Utilisé après les soumissions POST. La réponse dit « votre POST a fonctionné, voir cette URL GET pour le résultat ». Les navigateurs accèdent toujours à la nouvelle URL avec GET.

RFC 9110 ↗
304

Non modifié

La version mise en cache est toujours valide. Utilisez-la.

Réponse à une demande conditionnelle (avec les en-têtes If-None-Match ou If-Modified-Since). Économise la bande passante. Aucun corps n'est renvoyé.

RFC 9110 ↗
307

Redirection temporaire

Comme 302 mais conserve la méthode HTTP d'origine.

Si l'original était POST, la redirection utilise également POST. Alternative moderne au 302 lorsque la conservation de la méthode est importante.

RFC 9110 ↗
308

Redirection permanente

Comme 301 mais conserve la méthode HTTP d'origine.

Remplacement moderne du 301 lorsque vous souhaitez que les demandes POST restent POST après la redirection.

RFC 9110 ↗
400

Mauvaise demande

Le serveur n'a pas pu comprendre la demande en raison d'une syntaxe mal formée.

Causes courantes : JSON mal formé dans le corps, paramètres de requête invalides ou champs requis manquants. Vérifiez le corps de la demande et les en-têtes.

RFC 9110 ↗
401

Non autorisé

L'authentification est requise et n'a pas été fournie.

Le client doit inclure les identifiants d'authentification (en-tête Authorization, cookie, jeton). « Non autorisé » est un terme inexact. Cela signifie vraiment « non authentifié ».

RFC 9110 ↗
402

Paiement requis

Réservé à un usage futur. Parfois utilisé pour les niveaux d'API payants.

À l'origine destiné aux paiements numériques. Utilisation moderne : certaines API retournent 402 lorsqu'un utilisateur a dépassé son quota payant.

RFC 9110 ↗
403

Interdit

Le client est authentifié mais n'a pas la permission.

Différent du 401. L'utilisateur EST connecté, mais son compte n'a pas la permission pour cette ressource. Vérifiez la logique des rôles/permissions.

RFC 9110 ↗
404

Non trouvé

La ressource demandée n'existe pas.

L'URL est soit incorrecte, soit la ressource a été supprimée, soit elle n'a jamais existé. Les serveurs retournent parfois 404 pour masquer qu'un 403 serait plus approprié.

RFC 9110 ↗
405

Méthode non autorisée

La méthode HTTP utilisée n'est pas autorisée pour cette ressource.

Par exemple, une requête GET vers un point de terminaison qui n'accepte que POST. La réponse doit inclure un en-tête Allow listant les méthodes valides.

RFC 9110 ↗
406

Non acceptable

Aucune représentation ne correspond aux en-têtes Accept du client.

Le client a demandé un type de contenu, une langue ou un encodage (via Accept, Accept-Language, Accept-Encoding) que le serveur ne peut pas satisfaire. De nombreux serveurs ignorent la négociation stricte et retournent une valeur par défaut.

RFC 9110 ↗
407

Authentification proxy requise

Le client doit d'abord s'authentifier auprès du proxy.

Comme 401, mais émis par un proxy. Le client doit envoyer les identifiants Proxy-Authorization. Vu sur les réseaux d'entreprise avec des proxies d'authentification.

RFC 9110 ↗
408

Délai d'attente de la requête dépassé

Le serveur a expiré en attente de la requête.

Le client a mis trop de temps pour envoyer le corps de la requête ou a gardé la connexion inactive. Veuillez réessayer la requête.

RFC 9110 ↗
409

Conflit

La requête entre en conflit avec l'état actuel de la ressource.

Généralement retourné pour les conflits d'édition concurrente ou la création de ressources en double (par exemple, créer un utilisateur avec un e-mail qui existe déjà).

RFC 9110 ↗
410

Disparu

La ressource a été supprimée et ne reviendra pas.

Plus fort que 404 — le serveur sait explicitement que la ressource EXISTAIT autrefois mais a été supprimée de manière permanente. Les moteurs de recherche vont la retirer de l'index.

RFC 9110 ↗
411

Longueur requise

Le serveur exige un en-tête Content-Length.

La requête a été rejetée car elle n'avait pas d'en-tête Content-Length et le serveur refuse les corps de taille inconnue. Ajoutez l'en-tête et réessayez.

RFC 9110 ↗
412

Précondition non remplie

Une condition dans les en-têtes de la requête n'a pas été remplie.

Retourné lorsque les en-têtes conditionnels comme If-Match ou If-Unmodified-Since échouent — généralement verrouillage optimiste : quelqu'un d'autre a changé la ressource depuis votre version. Récupérez et réessayez.

RFC 9110 ↗
413

Charge utile trop importante

Le corps de la requête dépasse la limite de taille du serveur.

Courant lors du téléchargement de gros fichiers. La configuration du serveur (nginx, apache) définit une taille maximale du corps. Vérifiez la configuration du serveur.

RFC 9110 ↗
414

URI trop long

L'URL de la requête dépasse la limite de longueur du serveur.

Généralement causé par des chaînes de requête très longues (par exemple, encoder les données dans une GET). Passez à un corps POST ou augmentez la limite du serveur si vous le contrôlez.

RFC 9110 ↗
415

Type de média non pris en charge

Le serveur ne peut pas gérer le Content-Type envoyé.

Par exemple, envoyer application/xml à un serveur qui n'accepte que application/json. Définissez correctement l'en-tête Content-Type.

RFC 9110 ↗
416

Plage non satisfiable

La plage d'octets demandée est en dehors de la taille de la ressource.

L'en-tête Range demande une portion que le fichier ne possède pas — par exemple, reprendre un téléchargement au-delà de la fin du fichier. La réponse doit inclure Content-Range avec la taille réelle.

RFC 9110 ↗
417

Attente non satisfaite

Le serveur ne peut pas satisfaire les exigences de l'en-tête Expect.

Envoyé lorsque le serveur ne supporte pas Expect: 100-continue. Certains clients envoient cet en-tête par défaut sur les POST volumineux ; le désactiver résout généralement l'erreur.

RFC 9110 ↗
418

Je suis une théière

Le serveur refuse de faire du café parce que c'est une théière.

Une blague du 1er avril 1998 (RFC 2324). Certaines API réelles l'utilisent pour des blagues ou pour marquer les points de terminaison dépréciés. À ne pas utiliser en production.

RFC 2324 ↗
421

Requête mal adressée

La requête a été envoyée à un serveur incapable de produire une réponse.

Courant avec la réutilisation de connexion HTTP/2 : la requête a atteint un serveur qui n'est pas configuré pour le nom d'hôte cible. Le client doit réessayer sur une nouvelle connexion.

RFC 9110 ↗
422

Contenu non traitable

La requête était syntaxiquement valide mais sémantiquement incorrecte.

Par exemple, JSON analysé correctement mais un champ requis était manquant, ou une valeur de champ était hors limites. Courant dans les réponses de validation d'API REST.

RFC 9110 ↗
423

Verrouillé

La ressource est verrouillée.

WebDAV : la ressource source ou destination est verrouillée par un autre client, l'opération ne peut donc pas procéder. Attendez que le verrou soit libéré ou cassez-le avec le jeton approprié.

RFC 4918 ↗
424

Dépendance échouée

La requête a échoué car une requête dépendante précédente a échoué.

WebDAV : dans une chaîne d'opérations dépendantes, une action antérieure a échoué, celle-ci n'a donc pas été exécutée. Regardez l'échec antérieur pour la cause première.

RFC 4918 ↗
425

Trop tôt

Le serveur refuse de traiter une requête qui pourrait être rejouée.

Lié à TLS 1.3 0-RTT (données anticipées) : le serveur ne risquera pas de traiter une requête possiblement rejouée. Le client doit réessayer une fois la poignée de main terminée.

RFC 8470 ↗
426

Mise à niveau requise

Le client doit passer à un protocole différent.

Le serveur refuse de servir la requête sur le protocole actuel mais le fera après une mise à niveau — la réponse inclut un en-tête Upgrade nommant le protocole requis.

RFC 9110 ↗
428

Précondition requise

Le serveur exige que la requête soit conditionnelle.

Le serveur exige des en-têtes conditionnels (comme If-Match) pour prévenir les conflits de perte de mise à jour. Récupérez la ressource, capturez son ETag et renvoyez avec If-Match.

RFC 6585 ↗
429

Trop de requêtes

Le client est soumis à une limitation de débit.

Ralentissez. La réponse doit inclure un en-tête Retry-After indiquant quand réessayer. Courant avec les API qui ont des quotas de requête.

RFC 6585 ↗
431

Champs d'en-tête de requête trop importants

Les en-têtes sont trop importants pour être traités par le serveur.

Soit un en-tête, soit la taille totale des en-têtes dépasse la limite — le plus souvent causé par des cookies surdimensionnés. Effacez les cookies ou réduisez ce que votre application stocke dans les cookies.

RFC 6585 ↗
451

Indisponible pour des raisons légales

Accès refusé en raison de demandes légales.

La ressource est bloquée pour des raisons légales — censure, ordonnances judiciaires ou réglementations régionales. Le numéro est une allusion au roman Fahrenheit 451.

RFC 7725 ↗
500

Erreur interne du serveur

Le serveur a rencontré une condition inattendue.

Un fourre-tout générique pour les erreurs côté serveur. Vérifiez les journaux du serveur pour la cause réelle : exception non gérée, erreur de base de données, etc.

RFC 9110 ↗
501

Non implémenté

Le serveur ne supporte pas la fonctionnalité demandée.

Par exemple, le serveur ne reconnaît pas la méthode HTTP. Rare en pratique — vous verrez plus souvent 405.

RFC 9110 ↗
502

Mauvaise passerelle

Le serveur, agissant comme une passerelle, a reçu une mauvaise réponse d'un serveur en amont.

Courant dans les architectures de microservices. Votre équilibreur de charge ou proxy inverse a reçu une réponse mal formée du service backend.

RFC 9110 ↗
503

Service indisponible

Le serveur est temporairement incapable de gérer la requête.

Soit en maintenance, soit surchargé. La réponse doit inclure un en-tête Retry-After. Souvent retourné lors des déploiements.

RFC 9110 ↗
504

Délai d'expiration de la passerelle

Le serveur passerelle a expiré en attente d'une réponse en amont.

Le service backend n'a pas répondu assez vite. Vérifiez la santé du service en amont et les configurations de délai d'expiration.

RFC 9110 ↗
505

Version HTTP non prise en charge

Le serveur ne supporte pas la version HTTP utilisée dans la requête.

La version principale HTTP de la requête n'est pas prise en charge par le serveur. Presque jamais vu avec les clients modernes.

RFC 9110 ↗
506

La variante négocie également

Le serveur a une mauvaise configuration de négociation de contenu.

La négociation de contenu transparente s'est terminée en boucle : la variante choisie est elle-même configurée pour négocier. Indique une erreur de configuration du serveur.

RFC 2295 ↗
507

Stockage insuffisant

Le serveur est à court d'espace disque.

WebDAV d'origine mais parfois utilisé par les serveurs généraux. Signifie que le serveur ne peut pas enregistrer la requête en raison de contraintes de stockage.

RFC 4918 ↗
508

Boucle détectée

Le serveur a détecté une boucle infinie lors du traitement de la requête.

WebDAV : traiter une requête Depth: infinity a entré une boucle (par exemple, liaisons circulaires). L'opération a été arrêtée.

RFC 5842 ↗
510

Non étendu

Des extensions supplémentaires à la requête sont requises.

Du cadre obsolète d'extension HTTP : le serveur a besoin de plus d'informations avant de pouvoir satisfaire la requête. Effectivement inutilisé sur le web moderne.

RFC 2774 ↗
511

Authentification réseau requise

Le client doit s'authentifier pour obtenir l'accès au réseau.

Utilisé par les portails captifs (WiFi hôtel/aéroport) pour indiquer que l'utilisateur doit se connecter au réseau avant d'accéder aux sites externes.

RFC 6585 ↗

Utilisations courantes

  • Référence pour la conception d'APILors de la conception d'API REST, choisissez le code de statut correct pour chaque réponse.
  • Rechercher rapidement les codes d'erreurLorsque votre application retourne une erreur HTTP confuse, recherchez ce qu'elle signifie réellement.
  • En savoir plus sur les codes de statut HTTPRéférence complète pour les étudiants et les développeurs qui apprennent HTTP et REST.
  • Référence rapide lors d'incidentsLors d'incidents de production, recherchez rapidement ce que chaque code de statut signifie.
  • Référence pour la documentation de l'APILors de la rédaction de la documentation de l'API, établissez un lien vers des descriptions faisant autorité des codes de statut que vous renvoyez.

Comment ça marche

Cet outil est une référence côté client construite autour d'une table de correspondance codée en dur de 63 codes de statut HTTP couvrant les cinq classes (1xx–5xx), chacun annoté avec son numéro de RFC de référence. Il n'y a aucun appel serveur, aucune API externe, aucune requête réseau — tout le filtrage et l'affichage se font dans le navigateur avec les méthodes intégrées de tableau et de chaîne de JavaScript.

  1. 1
    La table de correspondance est chargée
    L'ensemble complet des 63 codes de statut enregistrés par l'IANA est intégré directement dans cet outil comme un tableau JavaScript, chaque entrée portant le code numérique, le nom canonique en anglais, la classe de catégorie, et la RFC spécifique qui le définit (par exemple RFC 9110 pour la plupart des codes HTTP/1.1, RFC 6585 pour 429 Too Many Requests, RFC 2324 pour 418 I'm a Teapot).
  2. 2
    Le filtre s'exécute en mémoire
    Pendant que vous tapez ou sélectionnez un filtre de catégorie, Array.filter de JavaScript s'exécute sur la liste en mémoire, faisant correspondre votre requête au numéro de code de statut, au nom canonique, et aux chaînes de description courte et longue avec String.includes — sans délai d'anti-rebond, sans aller-retour serveur.
  3. 3
    Les détails se développent avec un lien RFC
    Chaque résultat s'affiche comme un élément HTML details/summary. Développer une entrée révèle l'explication complète et un lien direct vers la RFC faisant autorité sur rfc-editor.org, afin que vous puissiez lire le texte exact de la spécification pour tout code.
  4. 4
    Liens profonds et copie dans le presse-papiers
    Ouvrir une entrée met à jour le hash de l'URL avec le numéro de code (par exemple #404), rendant la page partageable et adaptée aux favoris. Le bouton copier écrit la chaîne canonique (par exemple '404 Not Found') dans le presse-papiers via l'API navigator.clipboard du navigateur.

Outils associés

Questions fréquemment posées