Codes de statut HTTP — liste complète avec significations et exemples

Réponse intermédiaire : le serveur a reçu les en-têtes de la requête et le client peut envoyer le corps.

Envoyé automatiquement par les serveurs lorsqu’un client inclut « Expect: 100-continue » avant d’envoyer un corps volumineux, afin que le client ne gaspille pas de bande passante pour une requête qui serait rejetée.

Ne l’envoyez pas depuis le code applicatif comme statut final ; ce n’est jamais la réponse à une requête, seulement une étape avant la vraie réponse.

Sans objet

RFC 9110 §15.2.1

PUT /upload HTTP/1.1
Content-Length: 104857600
Expect: 100-continue

HTTP/1.1 100 Continue

Le serveur accepte de basculer la connexion vers le protocole indiqué dans l’en-tête Upgrade.

La réponse de handshake des connexions WebSocket (Upgrade: websocket) et, historiquement, des mises à niveau HTTP/1.1 vers h2c.

HTTP/2 et HTTP/3 ne l’utilisent pas ; les WebSockets sur HTTP/2 utilisent plutôt la méthode CONNECT étendue (RFC 8441).

Sans objet

RFC 9110 §15.2.2

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

Réponse intermédiaire indiquant au client que le serveur travaille encore sur une longue requête WebDAV, pour éviter qu’il n’abandonne par expiration.

WebDAV. Retiré de WebDAV dans la RFC 4918, mais toujours présent dans le registre IANA.

Uniquement sur d’anciens serveurs WebDAV traitant des opérations récursives lentes, comme un COPY ou un MOVE en profondeur.

Les nouvelles API devraient plutôt renvoyer 202 Accepted avec une URL de suivi pour les traitements longs.

Sans objet

RFC 2518 §10.1

HTTP/1.1 102 Processing

Réponse intermédiaire contenant des en-têtes Link pour que le navigateur commence le préchargement ou la préconnexion pendant que le serveur prépare la réponse finale.

Quand le HTML met du temps à être généré (rendu côté serveur, requêtes en base de données) et que vous savez de quels CSS, polices ou origines la page a besoin. Les navigateurs Chromium et Firefox tiennent compte des indications preload et preconnect dans les réponses 103 ; Safari tient compte de preconnect.

N’y placez pas d’en-têtes qui ne doivent s’appliquer qu’à la réponse finale, comme Set-Cookie ; les navigateurs ignorent la plupart des en-têtes d’une 103.

Sans objet

RFC 8297

HTTP/1.1 103 Early Hints
Link: </style.css>; rel=preload; as=style
Link: <https://cdn.example.com>; rel=preconnect

HTTP/1.1 200 OK
Content-Type: text/html

Réponse intermédiaire indiquant au client que l’envoi qu’il a commencé pourra être repris plus tard, et où.

Enregistrement IANA temporaire pour le brouillon IETF sur les envois reprenables ; pas encore une RFC définitive.

Expérimental : les serveurs qui implémentent le brouillon sur les envois reprenables l’envoient avec un en-tête Location pointant vers la ressource d’envoi.

Pas d’usage général tant que le brouillon n’est pas publié en RFC ; la plupart des clients et proxys ne le connaissent pas.

Sans objet

draft-ietf-httpbis-resumable-upload

HTTP/1.1 104 Upload Resumption Supported
Upload-Draft-Interop-Version: 6
Location: https://example.com/upload/b530ce8ff

La requête a réussi. Le contenu du corps dépend de la méthode : la ressource pour GET, le résultat de l’action pour POST.

La réponse de succès normale pour GET, et pour POST, PUT, PATCH ou DELETE lorsque vous renvoyez un corps décrivant le résultat.

Ne renvoyez pas 200 avec un message d’erreur dans le corps (« soft errors »). Les clients, la supervision, les caches et les moteurs de recherche lisent le code d’état, pas votre JSON.

Mis en cache par défaut (cache heuristique possible)

RFC 9110 §15.3.1

HTTP/1.1 200 OK
Content-Type: application/json

{"id": 42, "name": "Ada"}

La requête a réussi et a créé une ou plusieurs nouvelles ressources.

Après un POST (ou un PUT vers une nouvelle URL) qui crée quelque chose. Incluez un en-tête Location pointant vers la nouvelle ressource ; le corps la décrit généralement.

Ne l’utilisez pas si rien de nouveau n’a été créé, par exemple pour la mise à jour d’un enregistrement existant (utilisez 200 ou 204).

Mis en cache uniquement avec Cache-Control ou Expires explicite

RFC 9110 §15.3.2

HTTP/1.1 201 Created
Location: /users/42
Content-Type: application/json

{"id": 42}

La requête a été acceptée pour traitement, mais le traitement n’est pas terminé et peut encore échouer.

Travaux en file d’attente ou asynchrones : encodage vidéo, génération de rapports, imports en masse. Renvoyez un lien où le client peut suivre l’état de la tâche.

Ne l’utilisez pas pour signifier « succès » pour un traitement synchrone ; il ne promet explicitement rien quant au résultat.

Mis en cache uniquement avec Cache-Control ou Expires explicite

RFC 9110 §15.3.3

HTTP/1.1 202 Accepted
Location: /jobs/7f3a
Content-Type: application/json

{"status": "queued"}

Succès, mais un proxy de transformation a modifié la réponse 200 du serveur d’origine.

Uniquement par des intermédiaires qui modifient le contenu, comme un proxy qui compresse les images ou réécrit le HTML, pour indiquer au client qu’il ne s’agit pas de la réponse exacte de l’origine.

Les serveurs d’origine et les API ne devraient pas l’envoyer.

Mis en cache par défaut (cache heuristique possible)

RFC 9110 §15.3.4

HTTP/1.1 203 Non-Authoritative Information
Content-Type: image/webp

Succès, et il n’y a volontairement aucun corps.

DELETE réussi, PUT ou PATCH quand vous ne renvoyez pas la ressource mise à jour, enregistrement automatique d’un formulaire, ou réponse à une requête CORS preflight.

N’incluez jamais de corps ; les clients ne le liront pas, et en HTTP/1.1 un corps parasite corrompt la réponse suivante sur la connexion. Utilisez 200 si vous avez quelque chose à renvoyer.

Mis en cache par défaut (cache heuristique possible)

RFC 9110 §15.3.5

HTTP/1.1 204 No Content

Succès ; le client doit réinitialiser la vue du document, par exemple vider le formulaire qui a été soumis.

Interfaces de saisie où l’utilisateur soumet un formulaire et saisit aussitôt un autre enregistrement.

Les navigateurs n’implémentent pas la réinitialisation : en pratique, il se comporte comme 204. Ne doit pas contenir de corps.

Mis en cache uniquement avec Cache-Control ou Expires explicite

RFC 9110 §15.3.6

HTTP/1.1 205 Reset Content

Le serveur ne renvoie que la ou les plages d’octets demandées par le client avec un en-tête Range.

Déplacement dans une vidéo ou un audio, téléchargements reprenables et gestionnaires de téléchargement qui récupèrent un fichier en morceaux parallèles. Incluez Content-Range.

Ne l’envoyez que si la requête contenait un en-tête Range que vous respectez. Si vous ignorez Range, envoyez 200 avec le corps complet.

Mis en cache par défaut (cache heuristique possible)

RFC 9110 §15.3.7

GET /video.mp4 HTTP/1.1
Range: bytes=0-1023

HTTP/1.1 206 Partial Content
Content-Range: bytes 0-1023/146515
Content-Length: 1024

Le corps (XML) contient un statut distinct pour chacune de plusieurs ressources.

WebDAV

Opérations WebDAV comme PROPFIND qui portent sur de nombreuses ressources. Certaines API JSON l’empruntent pour des points de terminaison par lot.

Pour les API par lot, beaucoup d’équipes préfèrent 200 avec des résultats par élément, car les clients génériques traitent 207 comme un simple succès.

Mis en cache uniquement avec Cache-Control ou Expires explicite

RFC 4918 §11.1

HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"

Utilisé dans une réponse 207 pour indiquer qu’une ressource a déjà été listée plus haut et n’est donc pas répétée (évite les boucles avec les bindings).

WebDAV

Serveurs WebDAV qui prennent en charge les bindings (RFC 5842).

N’a pas de sens comme réponse de premier niveau en dehors de WebDAV.

Mis en cache uniquement avec Cache-Control ou Expires explicite

RFC 5842 §7.1

<D:status>HTTP/1.1 208 Already Reported</D:status>

Le serveur a répondu à un GET avec un delta (instance manipulation) appliqué à la ressource actuelle plutôt qu’avec la ressource complète.

Encodage delta pour HTTP (en-têtes A-IM / IM). Rarement déployé.

Non pris en charge par les navigateurs ; ne l’utilisez pas dans des API ordinaires.

Mis en cache uniquement avec Cache-Control ou Expires explicite

RFC 3229 §10.4.1

HTTP/1.1 226 IM Used
IM: vcdiff
ETag: "v2"

La ressource a plusieurs représentations et le client (ou l’utilisateur) doit en choisir une.

Rare : négociation de contenu pilotée par l’agent, par exemple pour proposer un document en plusieurs langues ou formats avec un lien vers chacun.

Les navigateurs ne choisissent pas automatiquement. Pour le choix de langue ou de format, une négociation côté serveur ou une page normale avec des liens fonctionne mieux.

Mis en cache par défaut (cache heuristique possible)

RFC 9110 §15.4.1

HTTP/1.1 300 Multiple Choices
Link: </doc.en.html>; rel=alternate; hreflang=en
Link: </doc.fr.html>; rel=alternate; hreflang=fr

La ressource a une nouvelle URL permanente, indiquée dans l’en-tête Location.

Changement de domaine, passage de HTTP à HTTPS, slugs modifiés, regroupement d’URL en double. Les moteurs de recherche transfèrent les signaux de classement vers la nouvelle URL.

Les navigateurs peuvent transformer un POST en GET en suivant une 301. Si la méthode doit être conservée (point de terminaison d’API déplacé), utilisez 308. Les navigateurs mettent les 301 en cache de façon agressive : testez avant de déployer.

Mis en cache par défaut (cache heuristique possible)

RFC 9110 §15.4.2

HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/new-page

La ressource se trouve temporairement à une autre URL ; continuez à utiliser l’URL d’origine à l’avenir.

Redirections temporaires : redirections de connexion, tests A/B, pages de maintenance, redirections géographiques ou linguistiques.

Les navigateurs transforment un POST en GET en suivant une 302 (comportement historique que la RFC autorise). Utilisez 303 pour « allez voir le résultat » après un POST, et 307 quand la méthode doit être préservée.

Mis en cache uniquement avec Cache-Control ou Expires explicite

RFC 9110 §15.4.3

HTTP/1.1 302 Found
Location: /login?next=%2Faccount

Redirige le client vers une autre URL, qu’il doit récupérer avec GET.

Le modèle Post/Redirect/Get : après le POST d’un formulaire, envoyez 303 vers la page de résultat pour qu’un rafraîchissement ne soumette pas à nouveau le formulaire.

Pas pour un contenu déplacé ; il n’indique rien sur un éventuel déplacement de l’URL d’origine.

Mis en cache uniquement avec Cache-Control ou Expires explicite

RFC 9110 §15.4.4

HTTP/1.1 303 See Other
Location: /orders/1234

Réponse à un GET ou HEAD conditionnel (If-None-Match ou If-Modified-Since) : la copie en cache du client est toujours valide.

Revalidation du cache : non stocké lui-même, mais il rafraîchit la réponse en cache que le client possède déjà.

Automatiquement par les serveurs et CDN quand l’ETag ou la date Last-Modified correspond, ce qui évite de transférer un corps inchangé.

N’envoyez jamais de corps. Ne l’envoyez pas en réponse à une requête non conditionnelle ; le client n’a rien à réutiliser.

Sans objet

RFC 9110 §15.4.5

GET /app.js HTTP/1.1
If-None-Match: "33a64df5"

HTTP/1.1 304 Not Modified
ETag: "33a64df5"
Cache-Control: max-age=3600

Obsolète. Indiquait autrefois au client de répéter la requête via un proxy indiqué dans Location.

Rien. Il a été déprécié pour des raisons de sécurité et les navigateurs l’ignorent.

Ne l’envoyez pas.

Mis en cache uniquement avec Cache-Control ou Expires explicite

RFC 9110 §15.4.6

HTTP/1.1 305 Use Proxy

Réservé. Il a été utilisé dans un brouillon pour « Switch Proxy » et n’est plus utilisé.

Rien.

Ne l’envoyez pas.

Sans objet

RFC 9110 §15.4.7

Redirection temporaire où le client doit répéter la requête avec la même méthode et le même corps.

Redirection temporaire de requêtes POST, PUT ou DELETE (point de terminaison d’API déplacé pour maintenance). Les navigateurs affichent aussi une 307 interne quand HSTS impose HTTPS.

Pour un déplacement permanent, utilisez 308. Pour « allez chercher le résultat avec GET », utilisez 303.

Mis en cache uniquement avec Cache-Control ou Expires explicite

RFC 9110 §15.4.8

HTTP/1.1 307 Temporary Redirect
Location: https://api2.example.com/v1/orders

Redirection permanente où le client doit répéter la requête avec la même méthode et le même corps.

Un point de terminaison d’API déplacé définitivement qui reçoit des POST ou PUT. Les moteurs de recherche le traitent comme une 301. Next.js et Vercel utilisent 308 par défaut pour les redirections permanentes.

Les très anciens clients (Internet Explorer sous Windows 7 et versions antérieures) ne le comprennent pas ; pour un simple déplacement de page, la 301 convient tout aussi bien.

Mis en cache par défaut (cache heuristique possible)

RFC 9110 §15.4.9

HTTP/1.1 308 Permanent Redirect
Location: https://example.com/api/v2/upload

Le serveur ne traitera pas la requête en raison d’une erreur du client : syntaxe incorrecte, cadrage invalide ou paramètres invalides.

JSON impossible à analyser, paramètre obligatoire manquant, valeur du mauvais type. Expliquez le problème dans le corps (le format problem+json de la RFC 9457 est un bon choix).

Pour une entrée bien formée qui enfreint des règles métier, beaucoup d’API utilisent 422. Pour les problèmes d’authentification, utilisez 401 ou 403.

Mis en cache uniquement avec Cache-Control ou Expires explicite

RFC 9110 §15.5.1

HTTP/1.1 400 Bad Request
Content-Type: application/problem+json

{"title": "Invalid JSON", "detail": "Unexpected token } at position 41"}

La requête ne contient pas d’identifiants d’authentification valides. Malgré son nom, il signifie « non authentifié ».

Pas de jeton, jeton expiré ou mauvais mot de passe. La réponse doit inclure un en-tête WWW-Authenticate décrivant comment s’authentifier.

Si l’utilisateur est connecté mais n’a pas l’autorisation, utilisez 403. N’envoyez pas de 401 sans WWW-Authenticate.

Mis en cache uniquement avec Cache-Control ou Expires explicite

RFC 9110 §15.5.2

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="api", error="invalid_token"

Réservé à un usage futur. Il n’a pas de sémantique standard.

Certaines API l’utilisent pour « quota épuisé, passez à une offre supérieure » ou pour un paiement échoué (Stripe renvoie 402 pour les cartes refusées).

Ne comptez pas sur la compréhension des clients ; décrivez le problème dans le corps.

Mis en cache uniquement avec Cache-Control ou Expires explicite

RFC 9110 §15.5.3

HTTP/1.1 402 Payment Required
Content-Type: application/json

{"error": "card_declined"}

Le serveur a compris la requête et sait qui vous êtes (ou ne s’en soucie pas), mais refuse d’y donner suite.

L’utilisateur authentifié n’a pas l’autorisation, une IP est bloquée, le listage de répertoires est désactivé, ou une règle de WAF s’est déclenchée. Se réauthentifier n’y changera rien.

Si les identifiants sont absents ou invalides, utilisez 401. Si révéler l’existence de la ressource constitue en soi une fuite, renvoyez plutôt 404.

Mis en cache uniquement avec Cache-Control ou Expires explicite

RFC 9110 §15.5.4

HTTP/1.1 403 Forbidden
Content-Type: application/json

{"error": "You do not have access to this project"}

Le serveur n’a pas de représentation actuelle pour l’URL, ou refuse de dire s’il en existe une.

URL inconnues, enregistrements supprimés quand vous ne suivez pas les suppressions, ou ressources masquées aux utilisateurs non autorisés.

Si la ressource a existé et a disparu définitivement, 410 l’indique explicitement. Ne renvoyez pas une page 200 qui dit « introuvable » (soft 404).

Mis en cache par défaut (cache heuristique possible)

RFC 9110 §15.5.5

HTTP/1.1 404 Not Found
Content-Type: text/html

L’URL existe, mais ne prend pas en charge cette méthode HTTP.

Un DELETE sur une ressource en lecture seule ou un POST sur une page acceptant uniquement GET. La réponse doit inclure un en-tête Allow listant les méthodes prises en charge.

Ne l’utilisez pas pour des problèmes d’autorisation (403) ni pour des méthodes que le serveur n’implémente pas du tout (501).

Mis en cache par défaut (cache heuristique possible)

RFC 9110 §15.5.6

HTTP/1.1 405 Method Not Allowed
Allow: GET, HEAD

Le serveur ne peut pas produire de réponse correspondant aux en-têtes Accept, Accept-Language ou Accept-Encoding de la requête.

Une API qui ne parle que JSON et reçoit « Accept: application/xml » sans solution de repli.

La plupart des serveurs ignorent les en-têtes Accept sans correspondance et envoient leur format par défaut, ce qui est généralement plus convivial.

Mis en cache uniquement avec Cache-Control ou Expires explicite

RFC 9110 §15.5.7

HTTP/1.1 406 Not Acceptable
Content-Type: application/json

{"supported": ["application/json"]}

Comme 401, mais le client doit s’authentifier auprès du proxy intermédiaire.

Envoyé par les proxys sortants (proxys d’entreprise), avec un en-tête Proxy-Authenticate.

Les serveurs d’origine ne devraient jamais l’envoyer.

Mis en cache uniquement avec Cache-Control ou Expires explicite

RFC 9110 §15.5.8

HTTP/1.1 407 Proxy Authentication Required
Proxy-Authenticate: Basic realm="corp-proxy"

Le serveur n’a pas reçu de requête complète dans le délai qu’il était prêt à attendre, et ferme la connexion.

Envoyé par les serveurs sur les connexions keep-alive inactives ou les envois lents. Les clients peuvent renvoyer la requête sur une nouvelle connexion.

Pas pour un traitement back-end lent ; c’est une 504 au niveau d’une passerelle ou simplement une réponse lente. Envoyez « Connection: close » avec.

Mis en cache uniquement avec Cache-Control ou Expires explicite

RFC 9110 §15.5.9

HTTP/1.1 408 Request Timeout
Connection: close

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

Créer un utilisateur dont l’e-mail existe déjà, modifier un enregistrement que quelqu’un d’autre a changé (version différente), supprimer un dossier non vide.

Pour l’échec de conditions If-Match / If-Unmodified-Since, utilisez 412. Pour les erreurs de validation, utilisez 400 ou 422.

Mis en cache uniquement avec Cache-Control ou Expires explicite

RFC 9110 §15.5.10

HTTP/1.1 409 Conflict
Content-Type: application/json

{"error": "Email already registered"}

La ressource existait ici, a définitivement disparu et n’a pas d’adresse de renvoi.

Produits arrêtés, promotions expirées, comptes supprimés, versions d’API retirées. Google traite 404 et 410 presque de la même façon, même si une 410 peut sortir de l’index un peu plus tôt.

Si le contenu a été déplacé, redirigez plutôt avec une 301. Si vous n’êtes pas sûr que ce soit définitif, utilisez 404.

Mis en cache par défaut (cache heuristique possible)

RFC 9110 §15.5.11

HTTP/1.1 410 Gone

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

Serveurs qui refusent les envois chunked et doivent connaître la taille du corps à l’avance.

Rarement nécessaire pour les applications ; généralement émis par le serveur web lui-même.

Mis en cache uniquement avec Cache-Control ou Expires explicite

RFC 9110 §15.5.12

HTTP/1.1 411 Length Required

Une condition des en-têtes de la requête (If-Match, If-Unmodified-Since, If-None-Match sur une écriture) s’est révélée fausse.

Concurrence optimiste : le client a envoyé If-Match avec un ancien ETag, ce qui signifie que quelqu’un d’autre a modifié la ressource avant lui.

Ne l’utilisez pas pour des échecs de règles métier sans rapport avec les en-têtes conditionnels (409 ou 422).

Mis en cache uniquement avec Cache-Control ou Expires explicite

RFC 9110 §15.5.13

PUT /docs/7 HTTP/1.1
If-Match: "v3"

HTTP/1.1 412 Precondition Failed
ETag: "v4"

Le corps de la requête est plus volumineux que ce que le serveur accepte de traiter. Appelé « Payload Too Large » avant la RFC 9110.

Envois au-delà de la limite (client_max_body_size de nginx, plafond d’API de 10 Mo). Si la limite est temporaire, ajoutez Retry-After.

Pour une URL trop longue, utilisez 414 ; pour des en-têtes trop volumineux, 431.

Mis en cache uniquement avec Cache-Control ou Expires explicite

RFC 9110 §15.5.14

HTTP/1.1 413 Content Too Large
Connection: close

La cible de la requête (URL) est plus longue que ce que le serveur accepte d’interpréter.

Chaînes de requête énormes, souvent un formulaire GET qui devrait être un POST, ou une boucle de redirection qui ajoute sans cesse des paramètres.

Déplacez les grandes entrées dans un corps de requête (POST) plutôt que d’augmenter la limite indéfiniment.

Mis en cache par défaut (cache heuristique possible)

RFC 9110 §15.5.15

HTTP/1.1 414 URI Too Long

Le serveur refuse la requête car le format du corps (Content-Type ou Content-Encoding) n’est pas pris en charge.

Un point de terminaison qui accepte du JSON et reçoit des données de formulaire ou du XML, ou un en-tête Content-Type manquant. Incluez Accept-Post ou Accept-Patch pour indiquer ce qui est accepté.

Pas pour un corps au bon format dont le contenu est invalide (400 ou 422).

Mis en cache uniquement avec Cache-Control ou Expires explicite

RFC 9110 §15.5.16

HTTP/1.1 415 Unsupported Media Type
Accept-Post: application/json

Aucune des plages d’octets de l’en-tête Range ne chevauche la ressource, par exemple une demande d’octets au-delà de la fin du fichier.

Téléchargements repris alors que le fichier a rétréci ou que le client demande au-delà de sa fin. Incluez Content-Range: bytes */<length>.

Les serveurs peuvent aussi simplement ignorer une plage invalide et renvoyer 200 avec le corps complet, ce qui est également autorisé.

Mis en cache uniquement avec Cache-Control ou Expires explicite

RFC 9110 §15.5.17

HTTP/1.1 416 Range Not Satisfiable
Content-Range: bytes */47022

Le serveur ne peut pas satisfaire l’exigence de l’en-tête Expect de la requête.

Un client a envoyé « Expect: 100-continue » à un serveur ou proxy qui ne le prend pas en charge, ou une attente inconnue.

Les clients qui le reçoivent devraient réessayer sans l’en-tête Expect.

Mis en cache uniquement avec Cache-Control ou Expires explicite

RFC 9110 §15.5.18

HTTP/1.1 417 Expectation Failed

Réservé par la RFC 9110 car 418 a été largement déployé comme code humoristique « I’m a teapot » ; il n’a aucune signification définie en HTTP.

Réservé. Célèbre sous le nom « I’m a teapot », issu de la RFC 2324 (HTCPCP), poisson d’avril de 1998.

Uniquement comme easter egg. Certains services l’utilisent pour rejeter des requêtes avec humour.

Ne l’utilisez pas pour de vraies erreurs ; aucune signification ne peut lui être attribuée et les clients ne sauront pas quoi faire.

Mis en cache uniquement avec Cache-Control ou Expires explicite

RFC 9110 §15.5.19

HTTP/1.1 418 I'm a teapot

Laravel le renvoie quand le jeton CSRF est absent ou expiré, généralement après l’expiration d’une session sur une page contenant un formulaire.

Envoyé par le middleware CSRF de Laravel. Pour corriger : rafraîchir la page, inclure @csrf dans les formulaires ou envoyer l’en-tête X-CSRF-TOKEN avec les requêtes AJAX.

Pas un code standard ; ne l’envoyez pas depuis des API non Laravel.

Sans objet

Laravel (absent du registre IANA)

HTTP/1.1 419 unknown status

La réponse de limitation de débit de l’ancienne API Twitter, remplacée par le code standard 429.

Rien de nouveau. Vous pouvez encore le rencontrer dans d’anciennes bibliothèques clientes. Spring a autrefois défini 420 « Method Failure », désormais obsolète.

Utilisez 429 pour la limitation de débit.

Sans objet

Twitter API v1 (absent du registre IANA)

HTTP/1.1 420 Enhance Your Calm

La requête a atteint un serveur qui ne peut pas produire de réponse pour cet hôte et ce schéma.

La fusion de connexions HTTP/2 a mal tourné : le navigateur a réutilisé une connexion pour un autre nom d’hôte couvert par le même certificat, mais le serveur ne le sert pas. Le client doit réessayer sur une nouvelle connexion.

Pas pour les noms d’hôte inconnus ordinaires sur un seul serveur ; c’est généralement une 404 ou l’hôte virtuel par défaut.

Mis en cache uniquement avec Cache-Control ou Expires explicite

RFC 9110 §15.5.20

HTTP/2 421

La requête est bien formée et dans un format pris en charge, mais son contenu échoue à la validation. Appelé « Unprocessable Entity » dans la RFC 4918.

Erreurs de validation de formulaires et d’API : un e-mail qui n’en est pas un, une date de fin antérieure à la date de début. Rails, Laravel et FastAPI l’utilisent par défaut.

Pour une syntaxe incorrecte (JSON impossible à analyser), utilisez 400.

Mis en cache uniquement avec Cache-Control ou Expires explicite

RFC 9110 §15.5.21

HTTP/1.1 422 Unprocessable Content
Content-Type: application/json

{"errors": {"email": ["is invalid"]}}

La ressource est verrouillée : la requête ne peut donc pas la modifier.

WebDAV

Sémantique LOCK de WebDAV. Certaines API l’utilisent pour des enregistrements en cours de modification par quelqu’un d’autre ou des comptes verrouillés après des échecs de connexion.

En dehors de WebDAV, 409 est mieux compris par les clients génériques.

Mis en cache uniquement avec Cache-Control ou Expires explicite

RFC 4918 §11.3

HTTP/1.1 423 Locked

L’action a échoué parce qu’une autre action dont elle dépendait a échoué.

WebDAV

Dans un PROPPATCH WebDAV ou une requête par lot, les éléments qui n’ont pas été tentés parce qu’un élément précédent a échoué.

Pas pour les pannes de services en amont ; ce sont des 502 ou 503.

Mis en cache uniquement avec Cache-Control ou Expires explicite

RFC 4918 §11.4

HTTP/1.1 424 Failed Dependency

Le serveur ne traitera pas une requête envoyée en early data TLS 1.3 (0-RTT), car elle pourrait être rejouée.

CDN et serveurs qui acceptent le 0-RTT mais rejettent les requêtes non idempotentes (POST) en early data. Le client réessaie une fois le handshake terminé.

Pas un code générique « réessayez plus tard » ; utilisez 503 avec Retry-After pour cela.

Mis en cache uniquement avec Cache-Control ou Expires explicite

RFC 8470 §5.2

HTTP/1.1 425 Too Early

Le serveur refuse la requête avec le protocole actuel, mais l’accepterait après une mise à niveau indiquée dans l’en-tête Upgrade.

Exiger TLS ou un protocole plus récent, ou un point de terminaison WebSocket appelé avec une requête HTTP simple. Doit inclure un en-tête Upgrade.

Pour passer de HTTP à HTTPS sur un site web, l’approche habituelle est une redirection 301 ou 308 avec HSTS.

Mis en cache uniquement avec Cache-Control ou Expires explicite

RFC 9110 §15.5.22

HTTP/1.1 426 Upgrade Required
Upgrade: TLS/1.3, HTTP/1.1
Connection: Upgrade

Le serveur exige que la requête soit conditionnelle (If-Match, etc.) pour éviter les mises à jour perdues.

API qui exigent que les clients envoient If-Match avec le dernier ETag vu avant un PUT, PATCH ou DELETE.

Utilisez 412 quand une précondition a été envoyée et a échoué ; 428 sert quand aucune n’a été envoyée.

Ne doit pas être stocké par les caches

RFC 6585 §3

HTTP/1.1 428 Precondition Required
Content-Type: application/json

{"error": "Send If-Match with the current ETag"}

Le client a envoyé trop de requêtes en un temps donné (limitation de débit).

Limites de débit d’API, limitation des tentatives de connexion, protection contre le scraping. Incluez Retry-After pour que les clients bien conçus sachent quand revenir ; les en-têtes RateLimit aident aussi.

Pour un serveur surchargé pour tout le monde, utilisez 503. Googlebot traite 429 comme 503 et ralentit son exploration.

Ne doit pas être stocké par les caches

RFC 6585 §4

HTTP/1.1 429 Too Many Requests
Retry-After: 60
Content-Type: application/json

{"error": "Rate limit exceeded: 100 requests per minute"}

Les en-têtes, individuellement ou ensemble, sont trop volumineux pour le serveur.

Généralement des cookies trop volumineux accumulés sur un domaine, ou des jetons Authorization énormes. Effacer les cookies résout souvent le problème pour les utilisateurs.

Pour une URL longue, utilisez 414 ; pour un corps volumineux, 413.

Ne doit pas être stocké par les caches

RFC 6585 §5

HTTP/1.1 431 Request Header Fields Too Large

La session du client a expiré et il doit se reconnecter (Outlook Web Access et autres applications IIS).

Rencontré dans les environnements Exchange/OWA.

Utilisez 401 pour les sessions expirées dans vos propres applications.

Sans objet

Microsoft IIS (absent du registre IANA)

HTTP/1.1 440 Login Time-out

Code interne à nginx : « return 444; » ferme la connexion sans envoyer la moindre réponse.

Rejeter les requêtes des scanners, les requêtes pour des en-têtes Host inconnus dans un bloc server par défaut, ou les clients abusifs. Il apparaît dans les journaux nginx ; le client reçoit une réponse vide.

Le client ne reçoit jamais de 444 : ce n’est donc pas à gérer dans le code client.

Sans objet

nginx (absent du registre IANA)

server {
  listen 80 default_server;
  return 444;
}

Extension Microsoft : la requête doit être renvoyée après que le client a effectué une action précise.

Rencontré dans certains services Microsoft (Exchange ActiveSync ; Azure Cosmos DB utilise 449 pour les conflits d’écriture qu’on peut retenter).

Non standard ; utilisez 409 ou 503 avec Retry-After dans vos propres API.

Sans objet

Microsoft IIS (absent du registre IANA)

HTTP/1.1 449 Retry With

Le contrôle parental de Windows a bloqué l’accès à la page.

Généré sur les systèmes Windows avec contrôle parental.

Ne l’envoyez pas depuis des serveurs.

Sans objet

Microsoft (absent du registre IANA)

HTTP/1.1 450 Blocked by Windows Parental Controls

L’accès est refusé en raison d’une exigence légale : décision de justice, censure gouvernementale ou restriction géographique pour des raisons juridiques.

Contenu bloqué dans une juridiction (sanctions, géoblocages liés au RGPD, injonctions de retrait). Un en-tête Link avec rel="blocked-by" peut indiquer qui l’a imposé.

Pas pour les refus d’autorisation ordinaires (403) ni pour un contenu que vous avez simplement choisi de retirer (410).

Mis en cache par défaut (cache heuristique possible)

RFC 7725 §3

HTTP/1.1 451 Unavailable For Legal Reasons
Link: <https://authority.example/>; rel="blocked-by"

Journalisé par un ALB AWS quand le client a fermé la connexion avant l’expiration du délai d’inactivité.

Rencontré dans les journaux d’accès ALB ; généralement un client dont le délai est plus court que le temps de traitement de la cible.

Non envoyé aux clients.

Sans objet

AWS Elastic Load Balancing (absent du registre IANA)

elb_status_code=460

L’ALB a reçu un en-tête X-Forwarded-For contenant plus de 30 adresses IP.

Généralement une boucle de proxy qui ajoute sans cesse des adresses.

Pas pour un usage applicatif.

Sans objet

AWS Elastic Load Balancing (absent du registre IANA)

HTTP/1.1 463

Code interne à nginx pour des en-têtes dépassant large_client_header_buffers ; le client reçoit une 400.

Apparaît dans les journaux nginx et la configuration error_page.

Le code standard est 431.

Sans objet

nginx (absent du registre IANA)

error_page 494 /header-too-large.html;

Interne à nginx : le client a présenté un certificat client invalide (TLS mutuel). Envoyé au client sous forme de 400.

Pages d’erreur personnalisées pour les échecs mTLS.

Pas un code d’état transmis sur le réseau.

Sans objet

nginx (absent du registre IANA)

error_page 495 /bad-client-cert.html;

Interne à nginx : un certificat client était requis mais n’a pas été fourni. Envoyé au client sous forme de 400.

Pages d’erreur personnalisées quand ssl_verify_client est activé.

Pas un code d’état transmis sur le réseau.

Sans objet

nginx (absent du registre IANA)

error_page 496 /client-cert-required.html;

Interne à nginx : une requête HTTP simple est arrivée sur un port qui attend du TLS. Envoyé au client sous forme de 400.

Une astuce courante est « error_page 497 =301 https://$host$request_uri; » pour rediriger ces requêtes vers HTTPS.

Pas un code d’état transmis sur le réseau.

Sans objet

nginx (absent du registre IANA)

error_page 497 =301 https://$host:$server_port$request_uri;

ArcGIS le renvoie pour un jeton expiré ou invalide pour une autre raison.

Pertinent uniquement lors d’appels aux services ArcGIS.

Utilisez 401 pour les jetons invalides dans vos propres API.

Sans objet

Esri ArcGIS (absent du registre IANA)

HTTP/1.1 498 Invalid Token

nginx journalise 499 quand le client a fermé la connexion avant que nginx n’envoie de réponse.

Rencontré dans les journaux d’accès : utilisateurs qui quittent la page, clients mobiles qui expirent, ou répartiteur de charge devant nginx avec un délai plus court. Beaucoup de 499 sur un même point de terminaison signifient généralement qu’il est trop lent.

Le client ne le reçoit jamais. Esri utilise aussi 499 pour « Token Required ».

Sans objet

nginx (absent du registre IANA)

203.0.113.9 - - [16/Oct/2026:10:12:01 +0000] "GET /report HTTP/1.1" 499 0

Le serveur a rencontré une condition inattendue qui l’a empêché de répondre à la requête.

Exceptions non gérées et bugs. C’est le repli générique quand aucun code 5xx plus précis ne s’applique.

Ne l’utilisez pas pour les erreurs du client (4xx). N’exposez pas de traces d’appels dans le corps en production ; journalisez-les plutôt.

Mis en cache uniquement avec Cache-Control ou Expires explicite

RFC 9110 §15.6.1

HTTP/1.1 500 Internal Server Error
Content-Type: application/problem+json

{"title": "Internal Server Error", "traceId": "4bf92f35"}

Le serveur ne prend pas en charge la fonctionnalité requise, généralement une méthode HTTP qu’il ne reconnaît pas du tout.

Une requête avec une méthode inconnue (p. ex. une méthode WebDAV sur un simple serveur web), ou une fonctionnalité que le serveur n’a délibérément pas encore développée.

Si la méthode est connue mais non autorisée sur cette URL, utilisez 405.

Mis en cache par défaut (cache heuristique possible)

RFC 9110 §15.6.2

HTTP/1.1 501 Not Implemented

Une passerelle ou un proxy a reçu une réponse invalide du serveur en amont.

Envoyé par les reverse proxys et répartiteurs de charge (nginx, Cloudflare, AWS ALB) quand le serveur d’application a planté, fermé la connexion ou renvoyé n’importe quoi.

Le code applicatif a rarement besoin de l’envoyer, sauf les passerelles d’API qui appellent un autre service en échec.

Mis en cache uniquement avec Cache-Control ou Expires explicite

RFC 9110 §15.6.3

HTTP/1.1 502 Bad Gateway
Server: nginx

Le serveur ne peut pas traiter la requête pour le moment : surcharge ou maintenance. Censé être temporaire.

Maintenance planifiée, délestage, panne d’une dépendance. Ajoutez Retry-After. Les moteurs de recherche gardent la page indexée pendant de courtes périodes de 503, contrairement à une page de maintenance en 200 ou à une 404.

Ne laissez pas un site en 503 pendant des jours ; Google finit par retirer les URL qui continuent de le renvoyer.

Mis en cache uniquement avec Cache-Control ou Expires explicite

RFC 9110 §15.6.4

HTTP/1.1 503 Service Unavailable
Retry-After: 3600

Une passerelle ou un proxy n’a pas reçu de réponse à temps du serveur en amont.

Envoyé par les proxys et répartiteurs de charge quand l’application met plus de temps que le délai du proxy (proxy_read_timeout de nginx vaut 60 secondes par défaut).

Pour les tâches longues, n’augmentez pas simplement les délais ; renvoyez 202 et traitez de façon asynchrone.

Mis en cache uniquement avec Cache-Control ou Expires explicite

RFC 9110 §15.6.5

HTTP/1.1 504 Gateway Timeout
Server: awselb/2.0

Le serveur ne prend pas en charge la version majeure de HTTP utilisée dans la requête.

Un serveur qui reçoit une version de protocole qu’il ne sait pas parler.

Rarement rencontré ; les clients négocient HTTP/2 et HTTP/3 via ALPN et Alt-Svc plutôt qu’à tâtons.

Mis en cache uniquement avec Cache-Control ou Expires explicite

RFC 9110 §15.6.6

HTTP/1.1 505 HTTP Version Not Supported

Erreur de configuration du serveur : la variante choisie est elle-même configurée pour négocier, ce qui crée une boucle.

Négociation de contenu transparente (expérimental)

Uniquement les serveurs qui implémentent la négociation de contenu transparente de la RFC 2295.

Pas pour les erreurs applicatives.

Mis en cache uniquement avec Cache-Control ou Expires explicite

RFC 2295 §8.1

HTTP/1.1 506 Variant Also Negotiates

Le serveur ne peut pas stocker ce qui est nécessaire pour mener à bien la requête.

WebDAV

API WebDAV ou de stockage de fichiers quand le disque ou le quota de l’utilisateur est plein.

Pour un envoi unique qui dépasse une limite de taille, 413 est plus clair.

Mis en cache uniquement avec Cache-Control ou Expires explicite

RFC 4918 §11.5

HTTP/1.1 507 Insufficient Storage

Le serveur a interrompu une opération car il a détecté une boucle infinie (bindings WebDAV avec Depth: infinity).

WebDAV

Serveurs WebDAV. Les hébergements mutualisés basés sur CloudLinux envoient aussi 508 « Resource Limit Is Reached » quand un compte atteint ses limites, ce qui n’est pas standard.

Pas pour les boucles de redirection ; ce sont des erreurs côté client que le navigateur signale lui-même.

Mis en cache uniquement avec Cache-Control ou Expires explicite

RFC 5842 §7.2

HTTP/1.1 508 Loop Detected

Le compte d’hébergement a dépassé son quota de bande passante.

Panneaux de contrôle d’hébergement mutualisé.

Utilisez 503 ou 429 dans vos propres systèmes.

Sans objet

Apache / cPanel (absent du registre IANA)

HTTP/1.1 509 Bandwidth Limit Exceeded

La requête ne respectait pas la politique d’accès à la ressource selon le HTTP Extension Framework.

Marqué obsolète dans le registre IANA : la RFC 2774 a été classée Historic.

Rien d’actuel ; le framework d’extension n’a jamais été largement implémenté.

Ne l’envoyez pas.

Mis en cache uniquement avec Cache-Control ou Expires explicite

RFC 2774 §7

HTTP/1.1 510 Not Extended

Le client doit s’authentifier pour accéder au réseau : un portail captif.

Portails Wi-Fi d’hôtels, d’aéroports et de cafés qui interceptent le trafic jusqu’à ce que l’utilisateur se connecte ou accepte les conditions.

Les serveurs d’origine ne doivent jamais l’envoyer ; il est réservé aux proxys réseau d’interception.

Ne doit pas être stocké par les caches

RFC 6585 §6

HTTP/1.1 511 Network Authentication Required
Content-Type: text/html

<meta http-equiv="refresh" content="0; url=https://login.example.net/">

L’origine a renvoyé à Cloudflare une réponse vide, inconnue ou inattendue.

Vérifiez les journaux de l’origine : plantages, réinitialisations de connexion, en-têtes au-delà de la limite de Cloudflare, ou réponse vide.

Seul Cloudflare l’envoie.

Sans objet

Cloudflare (absent du registre IANA)

HTTP/2 520
server: cloudflare

Cloudflare n’a pas pu se connecter à l’origine : la connexion a été refusée.

Le serveur web d’origine est arrêté, ou un pare-feu bloque les plages d’IP de Cloudflare.

Seul Cloudflare l’envoie.

Sans objet

Cloudflare (absent du registre IANA)

HTTP/2 521
server: cloudflare

Cloudflare a dépassé le délai en établissant une connexion TCP vers l’origine.

Origine surchargée, paquets rejetés par un pare-feu ou mauvaise IP d’origine dans le DNS.

Seul Cloudflare l’envoie.

Sans objet

Cloudflare (absent du registre IANA)

HTTP/2 522
server: cloudflare

Cloudflare ne parvient pas du tout à joindre l’origine, généralement un problème de routage ou un mauvais enregistrement DNS.

Vérifiez que les enregistrements DNS A/AAAA pointent vers la bonne IP, joignable.

Seul Cloudflare l’envoie.

Sans objet

Cloudflare (absent du registre IANA)

HTTP/2 523
server: cloudflare

Cloudflare s’est connecté à l’origine, mais celle-ci n’a pas envoyé de réponse HTTP dans le délai imparti (100 secondes par défaut).

Requêtes longues : déplacez le travail dans une tâche en arrière-plan et interrogez son état, ou diffusez la progression en continu.

Seul Cloudflare l’envoie.

Sans objet

Cloudflare (absent du registre IANA)

HTTP/2 524
server: cloudflare

Le handshake TLS entre Cloudflare et l’origine a échoué.

Origine qui n’écoute pas sur le port 443, absence de certificat, aucune suite de chiffrement commune ou SNI non configuré, alors que le mode SSL est Full ou Full (strict).

Seul Cloudflare l’envoie.

Sans objet

Cloudflare (absent du registre IANA)

HTTP/2 525
server: cloudflare

En mode Full (strict), Cloudflare n’a pas pu valider le certificat de l’origine : expiré, autosigné ou mauvais nom d’hôte.

Installez un certificat valide ou un certificat Cloudflare Origin CA sur l’origine.

Seul Cloudflare l’envoie.

Sans objet

Cloudflare (absent du registre IANA)

HTTP/2 526
server: cloudflare

Problème de connexion entre Cloudflare et un écouteur Railgun sur l’origine. Cloudflare a abandonné Railgun.

Historique uniquement.

Seul Cloudflare l’envoyait.

Sans objet

Cloudflare (absent du registre IANA)

HTTP/1.1 527 Railgun Error

Renvoyé avec une page d’erreur Cloudflare 1xxx (comme 1016 Origin DNS error) ; le code 1xxx affiché sur la page est la vraie cause.

Recherchez le numéro d’erreur 1xxx affiché sur la page.

Seuls les CDN et les hébergeurs l’envoient.

Sans objet

Cloudflare (absent du registre IANA)

HTTP/2 530
server: cloudflare

L’authentification intégrée de l’ALB (OIDC ou Cognito) a échoué auprès du fournisseur d’identité.

Vérifiez la configuration IdP de la règle d’écouteur de l’ALB.

Pas pour un usage applicatif.

Sans objet

AWS Elastic Load Balancing (absent du registre IANA)

HTTP/1.1 561

Utilisé par certains proxys pour signaler un délai de lecture dépassé derrière le proxy.

Rare ; vous pouvez le rencontrer avec certains produits proxy.

Utilisez 504.

Sans objet

Informal convention (absent du registre IANA)

HTTP/1.1 598

Utilisé par certains proxys et bibliothèques clientes (le client HTTP de Tornado, par exemple) pour un délai de connexion dépassé.

Rare.

Utilisez 504 pour les proxys.

Sans objet

Informal convention (absent du registre IANA)

HTTP/1.1 599