🌐 Web

Codes d'état HTTP

Signification et différences des codes de réponse HTTP de 100 à 500
Lire les données

Lire les codes d'état HTTP par groupes de centaines

Les codes d'état HTTP sont des codes de réponse standard qui indiquent comment le serveur a traité une requête. Comprendre d'abord les groupes 1xx, 2xx, 3xx, 4xx et 5xx aide à distinguer plus facilement les erreurs individuelles comme 404, 429, 451 et 500.

Comment la lire

Recherchez par numéro de code, nom anglais, description en français ou mots-clés associés, puis affinez par groupe de centaines ou par codes principaux/spéciaux. Cliquez sur un numéro de code pour accéder directement à la ligne correspondante.

Ce que montre cette page
  • Codes enregistrés et reason phrases standard selon l'IANA HTTP Status Code Registry
  • Sens, cas d'apparition, points à vérifier et codes associés pour chaque classe de centaines
  • Descriptions détaillées des codes très recherchés comme 451, 429, 404, 500 et 503
Base des données

Cette vue est préparée à partir de l'IANA HTTP Status Code Registry et de documents IETF tels que RFC 9110, RFC 7725 et RFC 6585.

Cette page est une référence expliquant le sens du protocole HTTP. Les décisions juridiques, de sécurité ou d'exploitation doivent aussi tenir compte de l'environnement de chaque service et de la documentation officielle.

Codes enregistrés 64
Classes d'état 5
Codes principaux 25
Codes spéciaux 21
1xx Information 5 2xx Succès 10 3xx Redirection 9 4xx Erreur client 29 5xx Erreur serveur 11
103 Early Hints 200 OK 206 Partial Content 301 Moved Permanently 302 Found 304 Not Modified 308 Permanent Redirect 400 Bad Request 401 Unauthorized 403 Forbidden 404 Not Found 410 Gone 413 Content Too Large 418 I'm a teapot 421 Misdirected Request 422 Unprocessable Content 425 Too Early 429 Too Many Requests 431 Request Header Fields Too Large 451 Unavailable For Legal Reasons 500 Internal Server Error 502 Bad Gateway 503 Service Unavailable 504 Gateway Timeout 511 Network Authentication Required
🌐 Liste complète des codes d'état HTTP
64 codes au total

1xx Information

Réponses intermédiaires indiquant que la requête a été reçue et que le traitement continue.

5
Signification Cas principaux À vérifier
100 Continue RFC 9110 Les en-têtes de la requête ont été reçus et le client peut continuer à envoyer le corps. Utilisé quand un serveur confirme si un corps de requête volumineux peut être envoyé avant que le client ne le transmette. Vérifiez l'en-tête Expect: 100-continue et le flux de traitement des uploads côté serveur. Associés: 417
101 Switching Protocols RFC 9110 Le serveur a accepté le changement de protocole demandé par le client. Vu lorsqu'une connexion HTTP est mise à niveau vers un autre protocole, comme WebSocket. Vérifiez l'en-tête Upgrade, l'en-tête Connection et si les proxies transmettent correctement la mise à niveau. Associés: 426
102 Processing RFC 2518 La requête a été reçue et reste en cours de traitement, mais la réponse finale n'est pas encore prête. Peut être utilisé par des requêtes WebDAV longues pour réduire le risque de timeout côté client. Vérifiez qu'une réponse finale arrive séparément et que le client ignore correctement les réponses intermédiaires. Associés: 207, 208
104 Temporaire Upload Resumption Supported IANA temporary registration Code de statut enregistré temporairement indiquant la prise en charge de la reprise d'upload. Peut apparaître dans des flux expérimentaux qui négocient une reprise par plages après l'interruption d'un upload volumineux. Comme il s'agit d'un enregistrement temporaire IANA, confirmez la prise en charge client et serveur avant de l'utiliser en production. Associés: 100, 201

2xx Succès

Réponses indiquant que la requête a été comprise et traitée correctement.

10
Signification Cas principaux À vérifier
200 OK RFC 9110 La requête a réussi et le corps de la réponse contient le résultat. Utilisé pour la plupart des réponses de succès ordinaires, notamment les vues de page, lectures d'API et résultats de formulaires. Vérifiez que le cache, le format du corps de réponse et Content-Type correspondent au résultat réel. Associés: 201, 204
201 Created RFC 9110 La requête a réussi et une nouvelle ressource a été créée. Approprié pour les requêtes POST qui créent des articles, commandes, comptes, fichiers ou ressources similaires. Vérifiez si l'emplacement de la nouvelle ressource est fourni via l'en-tête Location ou le corps de réponse. Associés: 200, 202, 204
202 Accepted RFC 9110 La requête a été acceptée, mais le traitement n'est pas encore terminé. Utilisé pour les tâches asynchrones, travaux en file et opérations batch dont le résultat sera déterminé plus tard. Incluez si possible une URL de statut, un ID de tâche ou des consignes de nouvelle tentative dans la réponse. Associés: 200, 201, 204
203 Non-Authoritative Information RFC 9110 Un proxy ou une couche de transformation a modifié puis transmis la réponse 200 du serveur d'origine. Peut être utilisé lorsqu'un intermédiaire fournit une représentation ou des métadonnées transformées. Vérifiez ensemble la réponse d'origine, la politique de transformation, les en-têtes Warning et les en-têtes de cache. Associés: 200, 214
204 No Content RFC 9110 La requête a réussi, mais la réponse ne contient pas de corps. Utilisé quand une suppression, sauvegarde, bascule ou action similaire réussit sans nécessiter de corps de réponse ni de navigation. N'envoyez pas de corps avec une réponse 204 et confirmez que le client ne traite pas une réponse vide comme une erreur. Associés: 200, 205
205 Reset Content RFC 9110 La requête a réussi et le client peut réinitialiser la vue de saisie. Peut être utilisé après l'envoi d'un formulaire pour demander au client de vider les champs sur le même écran. Il est rarement utilisé en pratique; confirmez que la réinitialisation de l'interface est bien l'expérience souhaitée. Associés: 204
206 Partial Content RFC 9110 Seule une partie de la ressource est renvoyée en réponse à une requête Range. Courant pour le streaming vidéo, les téléchargements reprenables et les requêtes partielles sur de gros fichiers. Vérifiez les en-têtes Range, Content-Range et Accept-Ranges ainsi que le comportement du cache CDN. Associés: 200, 416
207 Multi-Status RFC 4918 Réponse WebDAV portant les statuts de plusieurs sous-opérations dans une seule requête. Utilisé lorsque plusieurs ressources sont traitées ensemble et que chaque ressource doit avoir son propre résultat de succès ou d'échec. Analysez les statuts par ressource dans le corps de réponse; les API REST ordinaires utilisent généralement leur propre format de résultat. Associés: 102, 208
208 Already Reported RFC 5842 Indique qu'une ressource de liaison WebDAV a déjà été signalée et n'est pas répétée. Utilisé pour réduire les doublons lorsque la même ressource est référencée par plusieurs chemins dans une réponse WebDAV. Confirmez que le client WebDAV peut gérer 208 avec le corps de réponse 207. Associés: 207
226 IM Used RFC 3229 Le serveur a renvoyé un résultat après application d'une manipulation d'instance (IM). Défini pour le delta encoding et d'autres réponses basées sur des changements. Un flux spécial de cache et de transfert utilisant les en-têtes A-IM et IM est requis, il est donc rarement utilisé sur les sites ordinaires. Associés: 200, 206

3xx Redirection

Réponses indiquant qu'un autre emplacement ou une action supplémentaire est nécessaire pour terminer la requête.

9
Signification Cas principaux À vérifier
300 Multiple Choices RFC 9110 La ressource demandée possède plusieurs représentations ou choix. Peut être utilisé lorsque l'utilisateur ou le client doit choisir entre plusieurs langues, formats ou versions d'une même ressource. En pratique, les redirections avec un en-tête Location clair, comme 301, 302, 303, 307 et 308, sont plus courantes. Associés: 301, 302
301 Moved Permanently RFC 9110 La ressource a été déplacée définitivement vers une nouvelle URL. Utilisé pour les restructurations de site, changements de domaine et canonicalisation d'URL quand les moteurs de recherche doivent apprendre un déplacement permanent. Vérifiez l'en-tête Location, la durée de cache et si les liens internes ont été mis à jour depuis l'ancienne URL. Associés: 302, 308
302 Found RFC 9110 La ressource est temporairement disponible à une autre URL. Utilisé pour des déplacements non permanents, comme la navigation après connexion, les campagnes temporaires et les tests A/B. Si l'objectif est d'indiquer aux moteurs de recherche un déplacement permanent, vérifiez si 301 ou 308 serait plus approprié. Associés: 301, 303, 307
303 See Other RFC 9110 Le résultat de la requête doit être récupéré avec GET depuis une autre URL. Utile dans le modèle POST/Redirect/GET après traitement de formulaire, quand l'utilisateur est envoyé vers une page de résultat ou de fin. Comprenez que la méthode passe à GET et vérifiez le flux de prévention des soumissions de formulaire en double. Associés: 302, 307
304 Not Modified RFC 9110 Une requête conditionnelle a constaté que la ressource n'a pas changé, donc la copie en cache peut être utilisée. Courant quand les navigateurs ou CDNs revalident le cache avec If-None-Match ou If-Modified-Since. Vérifiez qu'ETag, Last-Modified et Cache-Control se comportent comme prévu. Associés: 200, 412
305 Use Proxy RFC 9110 Code hérité demandant au client d'utiliser un proxy; il est maintenant obsolète pour des raisons de sécurité. Il est plus sûr de le considérer comme inutilisé sur le web moderne. Ne l'utilisez pas dans de nouvelles implémentations; gérez la politique de proxy via la configuration ou la couche réseau. Associés: 407
306 Unused RFC 9110 Code de statut défini dans le passé, mais désormais réservé et inutilisé. Ne l'utilisez pas comme réponse serveur normale. S'il apparaît dans les logs, vérifiez les intermédiaires, le code de test ou les implémentations non standard. Associés: 305
307 Temporary Redirect RFC 9110 Redirection temporaire qui doit conserver la méthode et le corps de la requête. Plus clair que 302 lorsque POST, PUT ou une autre méthode doit être conservée en envoyant la requête vers un emplacement temporaire. Confirmez que le client ne transforme pas la méthode en GET et que la cible Location peut gérer la même requête. Associés: 302, 308
308 Permanent Redirect RFC 9110 Redirection permanente qui doit conserver la méthode et le corps de la requête. Appropriée lors du déplacement permanent d'endpoints d'API ou d'URLs où la conservation de la méthode importe. Définissez Location avec soin, car les moteurs de recherche et les caches clients peuvent le mémoriser longtemps. Associés: 301, 307

4xx Erreur client

Réponses indiquant que la requête ne peut pas être traitée à cause de conditions côté client, comme la syntaxe, l'authentification, l'autorisation ou l'état de la ressource.

29
Signification Cas principaux À vérifier
400 Bad Request RFC 9110 Le serveur ne peut pas traiter la requête car la syntaxe, les paramètres, les en-têtes ou le corps sont invalides. Courant avec du JSON invalide, des valeurs obligatoires manquantes, des URLs mal formées ou des en-têtes anormaux. Vérifiez le format du corps de requête, Content-Type, les paramètres de requête et les logs de validation du serveur. Associés: 422
401 Unauthorized RFC 9110 Une authentification est requise ou les identifiants fournis sont invalides. Utilisé lorsqu'un token de connexion manque, qu'une clé API a expiré ou que l'en-tête Authorization est incorrect. Vérifiez l'en-tête WWW-Authenticate, l'expiration du token, le schéma d'authentification et si les cookies sont envoyés. Associés: 403, 407
402 Payment Required RFC 9110 Réservé aux scénarios nécessitant un paiement, mais son sens standard n'est pas largement établi. Certaines API et services de paiement l'utilisent officieusement pour des problèmes de paiement, crédit ou abonnement. Consultez la documentation propre au service pour connaître le sens réel de 402 et le chemin de récupération. Associés: 403, 429
403 Forbidden RFC 9110 Le serveur a compris la requête, mais refuse d'autoriser l'accès. Courant avec des permissions insuffisantes, blocages IP, politiques administratives ou accès à des ressources privées. Vérifiez séparément la politique d'autorisation, les ACLs, les règles WAF, les permissions de fichiers et les règles de routage. Associés: 401, 404, 451
404 Not Found RFC 9110 La ressource demandée est introuvable, ou le serveur ne révèle pas si elle existe. Le plus courant avec des erreurs d'URL, pages supprimées, routes incorrectes ou ressources volontairement masquées. Vérifiez les liens internes, sitemaps, redirections, tables de routage et URLs de remplacement pour le contenu supprimé. Associés: 410, 403, 451
405 Method Not Allowed RFC 9110 La ressource existe, mais la méthode HTTP demandée n'est pas autorisée. Se produit lorsqu'un POST est envoyé à une URL seulement GET ou lorsqu'une route d'API est configurée pour d'autres méthodes. Vérifiez l'en-tête Allow, les définitions de méthodes du routeur et les politiques de restriction de méthode du proxy. Associés: 404, 501
406 Not Acceptable RFC 9110 Le serveur ne peut pas fournir une représentation correspondant aux en-têtes Accept du client. Peut se produire lorsque le client demande uniquement des types de médias, langues ou encodages non pris en charge. Vérifiez les en-têtes Accept, Accept-Language et Accept-Encoding ainsi que les paramètres de négociation de contenu du serveur. Associés: 415
407 Proxy Authentication Required RFC 9110 Une authentification est requise avant que le client puisse utiliser le proxy. Vu dans les réseaux d'entreprise, proxies de sécurité et environnements d'authentification de passerelle. Vérifiez les en-têtes Proxy-Authenticate et Proxy-Authorization ainsi que la configuration du proxy réseau. Associés: 401, 305
408 Request Timeout RFC 9110 Le serveur n'a pas reçu la requête client complète dans le délai qu'il était prêt à attendre. Peut arriver avec des réseaux lents, uploads volumineux, timeouts keep-alive ou timeouts de load balancer. Vérifiez le comportement de retry du client, la taille d'upload, les paramètres keep-alive et les valeurs de timeout du proxy. Associés: 504
409 Conflict RFC 9110 La requête est en conflit avec l'état actuel de la ressource. Souvent utilisé pour les créations en double, conflits de version, éditions concurrentes ou transitions d'état invalides. Vérifiez les versions de ressource, ETags, clés dupliquées et règles métier de transition d'état. Associés: 412, 422
410 Gone RFC 9110 La ressource existait auparavant, mais elle a été supprimée définitivement. Plus spécifique que 404 lorsque vous voulez indiquer clairement aux moteurs de recherche et clients qu'une page a été supprimée. Utilisez 301 s'il existe une URL de remplacement; utilisez 410 avec nettoyage du sitemap lorsque la suppression permanente est correcte. Associés: 404, 301
411 Length Required RFC 9110 Le serveur rejette la requête car elle n'inclut pas Content-Length. Peut se produire lorsqu'un serveur ou une passerelle doit connaître à l'avance la longueur du corps de requête. Vérifiez Content-Length, Transfer-Encoding et le comportement de streaming de la bibliothèque cliente. Associés: 413
412 Precondition Failed RFC 9110 Une précondition d'une requête conditionnelle, comme If-Match, a échoué. Utilisé pour prévenir les éditions concurrentes, revalider le cache et effectuer des mises à jour basées sur ETag. Comparez If-Match, If-None-Match et If-Unmodified-Since avec la version actuelle de la ressource. Associés: 304, 409, 428
413 Content Too Large RFC 9110 Le corps de la requête est plus volumineux que ce que le serveur accepte. Courant avec les limites d'upload de fichiers, limites de taille de corps JSON et restrictions de taille de corps côté proxy. Vérifiez les limites d'upload sur le serveur, le proxy, le CDN et l'application. Associés: 411, 431
414 URI Too Long RFC 9110 L'URI de la requête est plus longue que ce que le serveur peut traiter. Peut arriver avec de très longues query strings, des boucles de redirection défectueuses ou trop de données placées dans une URL GET. Déplacez les données longues dans un corps POST et vérifiez les limites de longueur d'URI dans les proxies et serveurs. Associés: 400, 431
415 Unsupported Media Type RFC 9110 Le serveur ne prend pas en charge le type de média du corps de la requête. Se produit lorsqu'une API JSON reçoit le mauvais Content-Type ou qu'un format de fichier non pris en charge est uploadé. Vérifiez Content-Type, l'extension de fichier, les paramètres multipart et si le parser serveur est enregistré. Associés: 406, 422
416 Range Not Satisfiable RFC 9110 La plage Range demandée ne peut pas être servie car elle ne correspond pas à la taille de la ressource. Se produit lors de téléchargements reprenables ou de streaming lorsque la plage demandée dépasse la taille du fichier. Vérifiez l'en-tête Range, Content-Range, la taille du fichier et les métadonnées de cache obsolètes. Associés: 206
417 Expectation Failed RFC 9110 Le serveur ne peut pas satisfaire l'attente indiquée dans l'en-tête Expect. Peut se produire lorsqu'un serveur ou proxy ne prend pas en charge des attentes comme Expect: 100-continue. Supprimez l'en-tête Expect ou confirmez que le serveur prend en charge le traitement 100 Continue. Associés: 100
422 Unprocessable Content RFC 9110 La syntaxe de la requête est valide, mais le contenu est sémantiquement impossible à traiter. Courant pour les échecs de validation d'API, violations de règles métier et valeurs de champs invalides. Décidez dans les règles de votre API si 400 signifie erreurs de format et 422 erreurs sémantiques ou de validation. Associés: 400, 409, 415
423 Locked RFC 4918 La ressource cible est verrouillée, la requête ne peut donc pas être traitée. Utilisé pour les verrous d'édition de fichiers, documents collaboratifs et verrous de ressources WebDAV. Vérifiez le propriétaire du verrou, son expiration, l'API de déverrouillage et la politique de gestion des conflits. Associés: 409, 424
424 Failed Dependency RFC 4918 La requête actuelle ne peut pas être exécutée car une opération dépendante précédente a échoué. Utilisé lorsque plusieurs opérations dépendent les unes des autres et que l'échec d'une opération antérieure fait échouer une opération suivante. Rendez claires dans le corps de réponse l'opération précédente échouée et la relation de dépendance. Associés: 207, 423
426 Upgrade Required RFC 9110 Le serveur exige que le client mette à niveau les protocoles avant de traiter la requête. Utilisé lorsqu'une mise à niveau précise est requise, comme une version HTTP, TLS ou WebSocket. Vérifiez l'en-tête Upgrade, les protocoles pris en charge et si les proxies transmettent les requêtes d'upgrade. Associés: 101
428 Precondition Required RFC 6585 Le serveur exige un en-tête de requête conditionnelle. Utilisé pour éviter les mises à jour perdues lors d'éditions concurrentes en exigeant une condition comme If-Match. Fournissez une documentation d'API et des messages d'erreur indiquant aux clients de lire l'ETag puis de mettre à jour avec If-Match. Associés: 412, 409
429 Too Many Requests RFC 6585 Le client a envoyé trop de requêtes pendant une période donnée. Courant avec les rate limits d'API, limites de tentatives de connexion, blocage de bots et rafraîchissements excessifs. Vérifiez Retry-After, les en-têtes de rate limit, les limites par utilisateur ou token et la stratégie de backoff. Associés: 403, 503
431 Request Header Fields Too Large RFC 6585 L'ensemble des en-têtes de requête ou un champ d'en-tête précis est trop volumineux. Peut se produire lorsque les cookies deviennent trop gros ou que des tokens d'authentification, en-têtes de suivi ou en-têtes ajoutés par proxy s'accumulent. Réduisez la taille de Cookie, de l'en-tête Authorization et des en-têtes ajoutés par les chaînes de proxies. Associés: 400, 413, 414

5xx Erreur serveur

Réponses indiquant que le serveur ou la passerelle n'a pas pu traiter une requête par ailleurs valide.

11
Signification Cas principaux À vérifier
500 Internal Server Error RFC 9110 Erreur serveur générale indiquant que la requête n'a pas pu être traitée à cause d'une défaillance interne. Utilisé lorsque des erreurs détaillées comme exceptions, configuration manquante, pannes de base de données ou échecs de rendu de template ne doivent pas être exposées au client. Vérifiez les logs applicatifs, le suivi d'erreurs, les déploiements récents et l'état des services dépendants. Associés: 502, 503, 504
501 Not Implemented RFC 9110 Le serveur ne prend pas en charge la fonctionnalité requise pour traiter la requête. Utilisé lorsqu'une méthode HTTP non prise en charge ou une fonctionnalité serveur non implémentée est demandée. 405 signifie que la méthode est interdite pour cette ressource; 501 indique plutôt que le serveur ne connaît pas du tout cette capacité. Associés: 405
502 Bad Gateway RFC 9110 Une passerelle ou un proxy a reçu une réponse invalide d'un serveur upstream. Courant avec les problèmes de connexion au serveur d'origine derrière un CDN, load balancer ou proxy inverse. Vérifiez la santé de l'origine, DNS, TLS, les paramètres upstream du proxy, ainsi que la taille et le format des en-têtes de réponse. Associés: 500, 503, 504
503 Service Unavailable RFC 9110 Le serveur est temporairement incapable de traiter la requête. Courant pendant une maintenance, surcharge, déploiement, panne backend ou délai d'autoscaling. Vérifiez Retry-After, les health checks, l'autoscaling, l'arriéré de file et la configuration de la page de maintenance. Associés: 429, 500, 502, 504
504 Gateway Timeout RFC 9110 Une passerelle ou un proxy n'a pas reçu à temps une réponse d'un serveur upstream. Courant avec la latence du serveur d'origine, des requêtes de base de données lentes, des délais d'API externes et des timeouts de load balancer. Vérifiez les valeurs de timeout upstream, le temps de traitement applicatif, le temps de réponse de la base de données ou de l'API externe et la politique de retry. Associés: 408, 502, 503
505 HTTP Version Not Supported RFC 9110 Le serveur ne prend pas en charge la version HTTP utilisée dans la requête. Peut se produire avec d'anciens clients, des proxies défectueux ou des restrictions de version HTTP côté serveur. Vérifiez la version HTTP du client, la négociation TLS/ALPN et les paramètres de traduction de protocole du proxy. Associés: 426
506 Variant Also Negotiates RFC 2295 Une erreur de configuration de négociation transparente de contenu a causé une boucle interne de négociation. Utilisé lorsque la négociation de contenu du serveur est mal configurée et que la variante choisie est elle-même configurée pour négocier. Vérifiez les paramètres de négociation de contenu, les mappings de variantes et les fichiers de configuration serveur. Associés: 300, 406
507 Insufficient Storage RFC 4918 Le serveur ne peut pas allouer le stockage nécessaire pour terminer la requête. Peut se produire avec WebDAV, uploads de fichiers, épuisement de quota de stockage ou manque d'espace disque. Vérifiez l'utilisation disque, le stockage des fichiers temporaires, les quotas utilisateur et les erreurs de stockage objet. Associés: 413, 500
508 Loop Detected RFC 5842 Le serveur a détecté une boucle infinie pendant le traitement de la requête. Peut être utilisé lorsqu'une requête WebDAV Depth ou une structure de références interne contient un cycle. Vérifiez le graphe de références de ressources, les liens symboliques, les bindings WebDAV et les limites de récursion. Associés: 508
510 Not Extended RFC 2774 Des extensions supplémentaires sont requises pour traiter la requête. Défini par le framework d'extensions HTTP, mais rarement utilisé dans les services web ordinaires. Consultez la documentation des exigences d'extension de l'API ou du serveur concerné. Associés: 501

Détails des codes HTTP les plus recherchés

Après avoir trouvé rapidement un code dans le tableau, consultez ci-dessous ses différences avec des codes proches.

HTTP 451 Indisponible pour raisons légales

451 est un code 4xx qui signale clairement que l'accès est indisponible pour des raisons légales.

HTTP 451 est utilisé lorsqu'un serveur, moteur de recherche, proxy ou intermédiaire ne peut pas fournir une ressource à cause d'une demande légale. Ce n'est pas seulement une absence de permission: il indique qu'une exigence juridique externe, comme une décision de justice, une demande gouvernementale, une action de copyright ou une réglementation locale, motive la restriction.

Lorsque vous voyez 451 dans des résultats de recherche ou un navigateur, il est plus exact de comprendre que la page n'est pas fournie pour des raisons légales dans l'emplacement de la requête ou selon la politique du service, plutôt que de supposer qu'elle a techniquement disparu. Lorsque c'est possible, les fournisseurs de service devraient expliquer dans le corps de réponse la partie bloquante ou la demande légale afin que les utilisateurs comprennent la situation.

Différence avec 403 403 signifie que l'accès est interdit par permission ou politique serveur; 451 est utilisé lorsque la raison de cette restriction est une exigence légale.
Différence avec 404 404 signifie que la ressource est introuvable ou que son existence est masquée; 451 signifie plus fortement que la ressource existe ou est connue, mais ne peut pas être fournie pour des raisons légales.
Différence avec 410 410 signifie que la ressource a été supprimée définitivement; 451 signifie que l'accès est restreint, que la ressource ait été supprimée ou non.

HTTP 429 Trop de requêtes

429 signifie qu'une limite de requêtes a été dépassée; il est particulièrement courant dans les API et la protection de connexion.

429 est utilisé lorsqu'un client envoie trop de requêtes sur une courte période. Il est lié aux politiques de stabilité du service et de prévention des abus, comme les limites d'usage, la défense anti-bot, les limites de tentatives de connexion et les quotas d'API des offres gratuites.

Les serveurs devraient fournir Retry-After ou des en-têtes de rate limit lorsque c'est possible afin que les clients sachent quand réessayer. Les clients devraient utiliser un backoff exponentiel et une mise en file plutôt que de répéter immédiatement les requêtes.

Différence avec 403 403 signifie que l'accès lui-même est interdit, tandis que 429 peut redevenir autorisé après un délai ou une récupération d'usage.
Différence avec 503 503 signifie que le serveur est temporairement incapable de traiter les requêtes; 429 signifie plus précisément qu'un client ou token particulier a dépassé un quota de requêtes.

HTTP 404 Introuvable

404 est le code d'erreur web le plus courant; il faut d'abord vérifier l'URL et l'état du contenu.

404 signifie que le serveur n'a pas trouvé la ressource demandée. Les utilisateurs l'interprètent généralement comme une faute dans l'URL ou une page supprimée, mais les serveurs peuvent aussi renvoyer 404 pour éviter de révéler l'existence d'une ressource protégée.

Pour la visibilité dans les moteurs de recherche, vérifiez les liens internes cassés, les anciens sitemaps et les pages de remplacement manquantes pour le contenu supprimé. Si un remplacement clair existe, 301 peut convenir; si la ressource est supprimée définitivement, 410 est aussi une option.

Différence avec 410 404 est une réponse générale d'introuvable, tandis que 410 signale que la ressource existait auparavant et a disparu définitivement.
Différence avec 403 403 signifie que le serveur a trouvé la ressource mais refuse l'accès; 404 signifie qu'elle n'a pas été trouvée ou que le serveur ne révèle pas si elle existe.

HTTP 500 Erreur interne du serveur

500 est une erreur large côté serveur indiquant qu'une exception ou une défaillance s'est produite pendant le traitement de la requête.

500 est utilisé lorsqu'un problème se produit dans la logique serveur, la configuration, les services dépendants ou le traitement des données plutôt que dans le format de la requête client. Il est souvent renvoyé comme code d'erreur généralisé pour éviter d'exposer des exceptions détaillées aux utilisateurs.

En exploitation, vérifiez d'abord les déploiements récents, les logs applicatifs, le suivi d'erreurs, les connexions à la base de données et les variables d'environnement manquantes. Si la même requête produit 500 de façon répétée, inspectez aussi les chemins de validation d'entrée et de gestion d'exceptions.

Différence avec 502 500 est une erreur interne du serveur actuel, tandis que 502 signifie qu'une passerelle a reçu une réponse invalide d'un serveur upstream.
Différence avec 503 503 convient mieux à une indisponibilité temporaire, comme une maintenance ou une surcharge.

HTTP 503 Service indisponible

503 signifie que le serveur est temporairement incapable de traiter la requête.

503 est utilisé lorsqu'un service ne peut temporairement pas accepter de requêtes à cause d'une maintenance, surcharge, déploiement, panne backend ou délai d'autoscaling. Pour les moteurs de recherche, il peut signaler un problème temporaire; une maintenance planifiée est donc souvent mieux représentée par 503 que par 500.

Incluez un en-tête Retry-After lorsque c'est possible pour indiquer quand le client doit réessayer. Vérifiez aussi les health checks du load balancer, l'arriéré de file, le nombre d'instances et les pannes de services dépendants.

Différence avec 500 500 couvre largement les erreurs internes, tandis que 503 indique plus clairement que le serveur ne peut temporairement pas traiter les requêtes.
Différence avec 429 429 signifie que le client demandeur a envoyé trop de requêtes, tandis que 503 est plus proche d'une perte de capacité de traitement du service entier, ou d'une partie de celui-ci.

Les codes d'état HTTP sont des signaux standardisant le sens des communications. Les causes réelles doivent être vérifiées avec les journaux applicatifs, la configuration proxy/CDN, les politiques d'authentification, les en-têtes de cache et l'historique des déploiements.

Sources et licences

Sources des données et conditions d'utilisation

Cette page s'appuie sur des données publiques fournies par les sources ci-dessous. Chaque donnée est soumise à la licence ou aux conditions d'utilisation de son fournisseur d'origine.

Source Données/API Conditions d'utilisation Traitement par Onul Works
IANA HTTP Status Code Registry Conditions d'utilisation Réorganise les codes enregistrés par l'IANA et les descriptions des RFC de l'IETF en groupes par centaines, balises de recherche et explications des codes principaux.
IETF / RFC Editor HTTP Semantics and status code RFCs Conditions d'utilisation Réorganise les codes enregistrés par l'IANA et les descriptions des RFC de l'IETF en groupes par centaines, balises de recherche et explications des codes principaux.

La normalisation, la traduction, la fusion, la mise en cache ou la conversion d'unités par Onul Works ne constituent ni une garantie ni une approbation de la part du fournisseur d'origine.