Les codes d’état HTTP sont le moyen de communication d’Internet entre les serveurs et les clients. Chaque fois que votre navigateur demande une page Web, qu’une API effectue un appel, ou qu’un serveur traite des données, ces codes à trois chiffres vous indiquent exactement ce qui s’est passé. Comprendre ces codes est essentiel pour les développeurs Web, les spécialistes SEO et toute personne travaillant avec les technologies Web.
Ce guide complet couvre tous les codes d’état HTTP standard de 100 à 511, organisés par catégorie. Chaque code d’état comprend des explications pratiques, des cas d’utilisation réels, des conseils de mise en œuvre et les pièges courants à éviter.
Référence rapide des codes d’état HTTP
| Code d’état | Nom | Catégorie | Aller à |
|---|---|---|---|
| 100 | Continue | Informationnel | Détails |
| 101 | Switching Protocols | Informationnel | Détails |
| 102 | Processing | Informationnel | Détails |
| 103 | Early Hints | Informationnel | Détails |
| 200 | OK | Succès | Détails |
| 201 | Created | Succès | Détails |
| 202 | Accepted | Succès | Détails |
| 203 | Non-Authoritative Information | Succès | Détails |
| 204 | No Content | Succès | Détails |
| 205 | Reset Content | Succès | Détails |
| 206 | Partial Content | Succès | Détails |
| 207 | Multi-Status | Succès | Détails |
| 208 | Already Reported | Succès | Détails |
| 226 | IM Used | Succès | Détails |
| 300 | Multiple Choices | Redirection | Détails |
| 301 | Moved Permanently | Redirection | Détails |
| 302 | Found | Redirection | Détails |
| 303 | See Other | Redirection | Détails |
| 304 | Not Modified | Redirection | Détails |
| 305 | Use Proxy (Deprecated) | Redirection | Détails |
| 307 | Temporary Redirect | Redirection | Détails |
| 308 | Permanent Redirect | Redirection | Détails |
| 400 | Bad Request | Erreur client | Détails |
| 401 | Unauthorized | Erreur client | Détails |
| 403 | Forbidden | Erreur client | Détails |
| 404 | Not Found | Erreur client | Détails |
| 405 | Method Not Allowed | Erreur client | Détails |
| 406 | Not Acceptable | Erreur client | Détails |
| 407 | Proxy Authentication Required | Erreur client | Détails |
| 408 | Request Timeout | Erreur client | Détails |
| 409 | Conflict | Erreur client | Détails |
| 410 | Gone | Erreur client | Détails |
| 418 | I’m a teapot | Erreur client | Détails |
| 422 | Unprocessable Entity | Erreur client | Détails |
| 429 | Too Many Requests | Erreur client | Détails |
| 451 | Unavailable For Legal Reasons | Erreur client | Détails |
| 500 | Internal Server Error | Erreur serveur | Détails |
| 501 | Not Implemented | Erreur serveur | Détails |
| 502 | Bad Gateway | Erreur serveur | Détails |
| 503 | Service Unavailable | Erreur serveur | Détails |
| 504 | Gateway Timeout | Erreur serveur | Détails |
| 505 | HTTP Version Not Supported | Erreur serveur | Détails |
| 507 | Insufficient Storage | Erreur serveur | Détails |
| 508 | Loop Detected | Erreur serveur | Détails |
| 511 | Network Authentication Required | Erreur serveur | Détails |
Réponses informationnelles 1xx
Ces codes indiquent que la demande a été reçue et que le processus se poursuit.
Qu’est-ce qu’un code d’état 100 ?
HTTP: 100 Continue
Quand et pourquoi les serveurs le retournent : Le serveur dit “J’ai reçu la première partie de votre demande, et elle semble correcte jusqu’à présent - allez-y et envoyez le reste !” Cela se produit lorsque vous essayez de télécharger quelque chose de volumineux (comme une vidéo), et le serveur veut vérifier si vous êtes autorisé à télécharger avant de perdre du temps à envoyer le fichier entier.
Cas d’utilisation pratiques : Téléchargement de fichiers volumineux vers le stockage cloud où le serveur vérifie d’abord si vous avez suffisamment d’espace, soumission de formulaires volumineux où le serveur valide votre connexion avant d’accepter toutes les données, ou toute situation où il est logique de vérifier les autorisations avant de transférer beaucoup de données.
Comment les clients doivent répondre à ce statut : Votre navigateur ou application doit immédiatement commencer à envoyer le reste des données. La plupart du temps, cela se produit automatiquement en arrière-plan - vous ne le remarquerez même pas.
Mauvais usages ou implémentations incorrectes : Envoyer ceci aux anciens navigateurs qui ne le comprennent pas, l’envoyer au hasard quand personne ne l’a demandé, ou oublier de vérifier si le client veut vraiment ce processus en deux étapes avant de l’utiliser.
Mozilla.org Developer Doc pour référence supplémentaire
Qu’est-ce qu’un code d’état 101 ?
HTTP: 101 Switching Protocols
Quand et pourquoi les serveurs le retournent : Le serveur accepte de changer la façon dont il communique avec vous. C’est comme passer des messages texte à un appel téléphonique - vous avez demandé à améliorer la connexion, et le serveur a dit “Bien sûr, faisons-le !”
Cas d’utilisation pratiques : Lorsqu’une application de chat passe du HTTP normal à WebSocket pour la messagerie en temps réel, lorsqu’un navigateur demande à utiliser une version plus rapide de HTTP, ou lorsque toute application doit passer à une méthode de communication différente pour de meilleures fonctionnalités.
Comment les clients doivent répondre à ce statut : Commencez immédiatement à utiliser le nouveau protocole de communication. C’est comme changer de langue au milieu d’une conversation - une fois que vous êtes tous les deux d’accord, vous commencez à parler la nouvelle langue tout de suite.
Mauvais usages ou implémentations incorrectes : Changer sans qu’on vous le demande, essayer de changer vers quelque chose que le serveur ne prend pas vraiment en charge, ou oublier de spécifier vers quel protocole vous passez.
Mozilla.org Developer Doc pour référence supplémentaire
Qu’est-ce qu’un code d’état 102 ?
HTTP: 102 Processing
Quand et pourquoi les serveurs le retournent : Le serveur dit “Je travaille toujours sur votre demande - ne m’abandonnez pas !” Ceci est utilisé lorsque quelque chose prend vraiment beaucoup de temps à traiter, donc le serveur envoie ce message pour vous empêcher de penser qu’il s’est planté.
Cas d’utilisation pratiques : Conversion d’un gros fichier vidéo vers un format différent, traitement de centaines de fichiers à la fois, exécution de rapports complexes qui prennent des minutes à générer, ou toute opération qui prend plus de temps que d’habitude pour se terminer.
Comment les clients doivent répondre à ce statut : Continuez à attendre patiemment. Le serveur peut envoyer plusieurs de ces messages “toujours en cours” avant de vous donner finalement le résultat réel. Ne réessayez pas la demande - cela recommencerait tout le processus.
Mauvais usages ou implémentations incorrectes : Utiliser ceci pour des opérations rapides qui n’en ont pas besoin, envoyer trop de messages “toujours en cours”, ou oublier d’envoyer la réponse finale après avoir dit que vous traitez.
Mozilla.org Developer Doc pour référence supplémentaire
Qu’est-ce qu’un code d’état 103 ?
HTTP: 103 Early Hints
Quand et pourquoi les serveurs le retournent : Le serveur vous donne un indice sur les ressources dont vous aurez probablement besoin bientôt. C’est comme un restaurant qui vous dit “pendant que je prépare votre commande, vous voudrez peut-être prendre vos serviettes et ustensiles”.
Cas d’utilisation pratiques : Dire aux navigateurs de commencer à charger les fichiers CSS et JavaScript pendant que le serveur prépare le HTML, précharger les polices dont la page aura besoin, ou réchauffer les connexions à d’autres serveurs que la page utilisera.
Comment les clients doivent répondre à ce statut : Commencez à charger les ressources suggérées en arrière-plan en attendant la vraie réponse. Cela rend les pages plus rapides car certains travaux commencent tôt.
Mauvais usages ou implémentations incorrectes : Envoyer des indices mais ne jamais envoyer la réponse réelle, suggérer des ressources qui ne sont pas réellement nécessaires, ou surcharger le client avec trop d’indices de préchargement inutiles.
Mozilla.org Developer Doc pour référence supplémentaire
Succès 2xx
Ces codes indiquent que la demande a été reçue, comprise et acceptée avec succès.
Qu’est-ce qu’un code d’état 200 ?
HTTP: 200 OK
Quand et pourquoi les serveurs le retournent : C’est la réponse “tout a parfaitement fonctionné”. Le serveur a trouvé ce que vous vouliez, a fait ce que vous avez demandé, et voici votre résultat. C’est le message de succès le plus courant que vous verrez.
Cas d’utilisation pratiques : Chargement de n’importe quelle page Web avec succès, obtention de données à partir d’une API, téléchargement d’un fichier, soumission d’un formulaire qui a fonctionné correctement, ou essentiellement chaque fois qu’une demande réussit sans aucun problème.
Comment les clients doivent répondre à ce statut : Utilisez les données qui sont revenues - affichez la page Web, traitez les données JSON, enregistrez le fichier, ou tout ce qui est logique pour votre application. C’est la réponse “normale” que tout est conçu pour gérer.
Mauvais usages ou implémentations incorrectes : Dire “200 OK” mais inclure un message d’erreur dans la réponse (confus !), utiliser 200 quand vous avez créé quelque chose de nouveau (utilisez 201 à la place), ou retourner 200 sans données quand des données étaient attendues.
Mozilla.org Developer Doc pour référence supplémentaire
Qu’est-ce qu’un code d’état 201 ?
HTTP: 201 Created
Quand et pourquoi les serveurs le retournent : Le serveur a créé avec succès quelque chose de nouveau basé sur votre demande. Ce n’est pas juste “OK” - c’est spécifiquement “J’ai fait la nouvelle chose que vous avez demandée !”
Cas d’utilisation pratiques : Création d’un nouveau compte utilisateur, publication d’un nouveau tweet ou mise à jour de statut, téléchargement d’un fichier qui est enregistré en tant que nouvelle ressource, ajout d’un nouveau produit à un panier d’achat, ou chaque fois que votre demande aboutit à quelque chose de nouveau étant stocké.
Comment les clients doivent répondre à ce statut : Recherchez l’en-tête Location qui vous indique généralement où trouver la chose nouvellement créée. Vous pouvez rediriger vers la nouvelle ressource ou mettre à jour votre interface utilisateur pour montrer que la création a réussi.
Mauvais usages ou implémentations incorrectes : Utiliser 201 lors de la mise à jour de choses existantes (c’est à cela que sert 200), oublier d’inclure l’emplacement de la nouvelle ressource, ou utiliser 201 quand rien n’a été réellement créé.
Mozilla.org Developer Doc pour référence supplémentaire
Qu’est-ce qu’un code d’état 202 ?
HTTP: 202 Accepted
Quand et pourquoi les serveurs le retournent : Le serveur a accepté votre demande mais n’a pas encore fini de la traiter. C’est comme déposer du linge à nettoyer - ils ont pris vos vêtements et vous ont donné un reçu, mais le nettoyage n’est pas encore fait.
Cas d’utilisation pratiques : Envoi d’emails (accepté pour la livraison mais pas encore envoyé), démarrage d’une grande exportation de données qui sera envoyée par email une fois prête, travaux de traitement vidéo, ou toute tâche qui est mise en file d’attente pour un traitement ultérieur.
Comment les clients doivent répondre à ce statut : N’attendez pas de résultats immédiats. Vous aurez besoin d’un autre moyen de vérifier si le travail est terminé - peut-être interroger un autre point de terminaison, attendre un email, ou vérifier une notification webhook.
Mauvais usages ou implémentations incorrectes : Utiliser 202 pour des choses qui se sont réellement déjà terminées, ne pas fournir de moyen de vérifier le statut plus tard, ou utiliser 202 quand la tâche pourrait échouer (sans avertir le client de cette possibilité).
Mozilla.org Developer Doc pour référence supplémentaire
Qu’est-ce qu’un code d’état 203 ?
HTTP: 203 Non-Authoritative Information
Quand et pourquoi les serveurs le retournent : La demande a réussi, mais la réponse a été modifiée par quelque chose au milieu (comme un proxy ou un cache). C’est comme jouer au téléphone arabe - le message est passé, mais il a peut-être légèrement changé en cours de route.
Cas d’utilisation pratiques : Lorsqu’un proxy d’entreprise ajoute ou supprime certains en-têtes, lorsqu’un serveur de mise en cache modifie les réponses pour économiser la bande passante, ou lorsque les filtres de contenu ajustent ce que vous voyez en fonction des politiques.
Comment les clients doivent répondre à ce statut : Utilisez la réponse normalement, mais sachez qu’elle peut ne pas être exactement ce que le serveur d’origine a envoyé. Elle est toujours valide, juste potentiellement modifiée.
Mauvais usages ou implémentations incorrectes : Ne pas être transparent sur les modifications, utiliser 203 quand rien n’a été réellement modifié, ou modifier les réponses de manières qui cassent la fonctionnalité.
Mozilla.org Developer Doc pour référence supplémentaire
Qu’est-ce qu’un code d’état 204 ?
HTTP: 204 No Content
Quand et pourquoi les serveurs le retournent : Le serveur a réussi à faire ce que vous avez demandé mais n’a rien à vous renvoyer. C’est comme supprimer quelque chose avec succès - la suppression a fonctionné, mais il n’y a rien à vous montrer parce que c’est parti !
Cas d’utilisation pratiques : Suppression d’enregistrements, mise à jour de paramètres où vous n’avez pas besoin de données de confirmation en retour, enregistrement de préférences silencieusement en arrière-plan, ou toute action réussie où un corps de réponse serait inutile.
Comment les clients doivent répondre à ce statut : Traitez-le comme un succès mais n’attendez aucune donnée. Parfait pour les requêtes AJAX où vous devez juste savoir que quelque chose a fonctionné. La page ne doit pas s’actualiser ou changer sauf si votre JavaScript décide de mettre à jour quelque chose.
Mauvais usages ou implémentations incorrectes : Inclure des données de réponse avec un 204 (ce n’est pas permis !), utiliser 204 quand le client veut probablement voir les données mises à jour, ou utiliser 204 pour les erreurs.
Mozilla.org Developer Doc pour référence supplémentaire
Qu’est-ce qu’un code d’état 205 ?
HTTP: 205 Reset Content
Quand et pourquoi les serveurs le retournent : Le serveur dit à votre application d’effacer son formulaire ou de réinitialiser sa vue. C’est comme soumettre un sondage avec succès et avoir le formulaire qui se vide automatiquement pour la personne suivante.
Cas d’utilisation pratiques : Après la soumission d’un formulaire de saisie de données qui doit être utilisé à plusieurs reprises, complétion d’un sondage qui devrait se réinitialiser pour le répondant suivant, ou toute situation où l’interface utilisateur devrait revenir à son état de départ après le succès.
Comment les clients doivent répondre à ce statut : Effacez tous les champs de formulaire, réinitialisez la vue du document, ou retournez l’interface à son état d’origine. Aucune donnée ne vient avec cette réponse - c’est juste une instruction de réinitialisation.
Mauvais usages ou implémentations incorrectes : Envoyer des données avec une réponse 205 (elle devrait être vide), utiliser 205 quand vous ne voulez pas réellement que le formulaire soit effacé, ou l’utiliser quand un simple 204 serait mieux.
Mozilla.org Developer Doc pour référence supplémentaire
Qu’est-ce qu’un code d’état 206 ?
HTTP: 206 Partial Content
Quand et pourquoi les serveurs le retournent : Le serveur n’envoie qu’une partie du fichier parce que c’est ce que vous avez demandé. C’est comme demander les pages 50-60 d’un livre au lieu du livre entier.
Cas d’utilisation pratiques : Streaming vidéo où vous pouvez sauter à différentes parties, reprise de téléchargements interrompus à partir de l’endroit où ils se sont arrêtés, téléchargement de fichiers volumineux en morceaux, ou mise en œuvre efficace des fonctionnalités “charger plus”.
Comment les clients doivent répondre à ce statut : Traitez le contenu partiel et demandez potentiellement plus de parties si nécessaire. Les lecteurs vidéo utilisent ceci pour la recherche, et les gestionnaires de téléchargement l’utilisent pour la reprise.
Mauvais usages ou implémentations incorrectes : Envoyer 206 quand personne n’a demandé de contenu partiel, envoyer la mauvaise plage d’octets, ne pas prendre en charge les demandes de plage quand elles seraient utiles, ou gâcher les en-têtes Content-Range.
Mozilla.org Developer Doc pour référence supplémentaire
Qu’est-ce qu’un code d’état 207 ?
HTTP: 207 Multi-Status
Quand et pourquoi les serveurs le retournent : Plusieurs opérations ont été effectuées et chacune a son propre résultat. C’est comme soumettre un lot de candidatures à un emploi et obtenir des réponses individuelles pour chacune dans une seule enveloppe.
Cas d’utilisation pratiques : Opérations en masse où vous mettez à jour plusieurs éléments à la fois, opérations WebDAV sur plusieurs fichiers, demandes API par lots, ou chaque fois que vous devez signaler des résultats individuels pour plusieurs opérations.
Comment les clients doivent répondre à ce statut : Analysez le corps de la réponse (généralement XML) pour voir le résultat individuel pour chaque opération. Certaines peuvent avoir réussi tandis que d’autres ont échoué, et vous devez gérer chacune de manière appropriée.
Mauvais usages ou implémentations incorrectes : Utiliser 207 pour des opérations uniques, ne pas structurer correctement la réponse multi-statut, ou l’utiliser quand toutes les opérations ont eu le même résultat (utilisez simplement ce code de statut unique à la place).
Mozilla.org Developer Doc pour référence supplémentaire
Qu’est-ce qu’un code d’état 208 ?
HTTP: 208 Already Reported
Quand et pourquoi les serveurs le retournent : Dans une réponse multi-statut, cela indique que les informations sur cette ressource ont déjà été incluses plus tôt. C’est comme dire “voir ci-dessus” pour éviter de se répéter.
Cas d’utilisation pratiques : Lors de la liste du contenu d’un répertoire qui inclut des liens symboliques, prévention des boucles infinies dans les opérations récursives, ou éviter les informations en double dans les réponses WebDAV complexes.
Comment les clients doivent répondre à ce statut : Ignorez le traitement de cette ressource puisque vous l’avez déjà gérée plus tôt dans la réponse. Cela empêche le double traitement et les boucles infinies.
Mauvais usages ou implémentations incorrectes : Utiliser 208 en dehors des contextes multi-statut appropriés, marquer des choses comme “déjà signalées” quand elles ne l’étaient pas, ou créer des réponses déroutantes en surutilisant ce statut.
Mozilla.org Developer Doc pour référence supplémentaire
Qu’est-ce qu’un code d’état 226 ?
HTTP: 226 IM Used
Quand et pourquoi les serveurs le retournent : Le serveur a appliqué une ou plusieurs transformations à la réponse. C’est comme commander un document et recevoir une version compressée ou optimisée pour économiser la bande passante.
Cas d’utilisation pratiques : Encodage delta où seuls les changements depuis la dernière fois sont envoyés, systèmes de compression qui transforment le contenu à la volée, ou toute transformation d’économie de bande passante que le client a demandée.
Comment les clients doivent répondre à ce statut : Traitez le contenu transformé en utilisant la méthode indiquée dans les en-têtes. Le client doit comprendre la transformation pour utiliser la réponse correctement.
Mauvais usages ou implémentations incorrectes : Utiliser 226 sans indiquer quelles transformations ont été appliquées, appliquer des transformations que le client n’a pas demandées, ou utiliser 226 pour la compression standard (qui n’a pas besoin d’un statut spécial).
Mozilla.org Developer Doc pour référence supplémentaire
Redirection 3xx
Ces codes indiquent qu’une action supplémentaire doit être prise pour compléter la demande.
Qu’est-ce qu’un code d’état 300 ?
HTTP: 300 Multiple Choices
Quand et pourquoi les serveurs le retournent : Il existe plusieurs versions de la ressource demandée et le serveur ne peut pas en choisir une automatiquement. C’est comme demander “le manuel” quand il existe des versions dans différentes langues.
Cas d’utilisation pratiques : Lorsque le contenu est disponible en plusieurs langues ou formats, lorsqu’il existe différentes versions pour différents appareils, ou lorsque le serveur ne peut vraiment pas décider quelle version vous voulez.
Comment les clients doivent répondre à ce statut : Présentez les choix à l’utilisateur ou choisissez-en un en fonction des préférences (comme les paramètres de langue). La réponse devrait lister toutes les options disponibles.
Mauvais usages ou implémentations incorrectes : Utiliser 300 quand le serveur pourrait raisonnablement choisir une valeur par défaut, ne pas présenter clairement les choix disponibles, ou l’utiliser pour des redirections simples (utilisez 301/302 à la place).
Mozilla.org Developer Doc pour référence supplémentaire
Qu’est-ce qu’un code d’état 301 ?
HTTP: 301 Moved Permanently
Quand et pourquoi les serveurs le retournent : La ressource a été déplacée de façon permanente vers une nouvelle adresse. C’est comme lorsqu’une entreprise déménage dans un nouveau lieu et met un panneau de transfert permanent - mettez à jour votre carnet d’adresses !
Cas d’utilisation pratiques : Lorsque les sites Web restructurent leurs URL de façon permanente, passage de HTTP à HTTPS, lorsque les entreprises changent de marque et changent de domaines, ou consolidation de plusieurs pages en une pour une meilleure organisation.
Comment les clients doivent répondre à ce statut : Allez automatiquement vers la nouvelle URL et souvenez-vous-en pour la prochaine fois. Les navigateurs mettent à jour les signets, et les moteurs de recherche mettent à jour leurs index pour pointer vers le nouveau lieu.
Mauvais usages ou implémentations incorrectes : Utiliser 301 pour des déplacements temporaires (utilisez 302 à la place), créer des chaînes de redirections qui font rebondir les utilisateurs, ou utiliser 301 quand vous pourriez vouloir le changer plus tard.
Mozilla.org Developer Doc pour référence supplémentaire
Qu’est-ce qu’un code d’état 302 ?
HTTP: 302 Found
Quand et pourquoi les serveurs le retournent : La ressource est temporairement à un endroit différent. C’est comme un panneau de magasin disant “Nous sommes au marché fermier aujourd’hui” - ils seront de retour à leur emplacement normal demain.
Cas d’utilisation pratiques : Redirection des utilisateurs pendant la maintenance du site, tests A/B où certains utilisateurs vont vers une version différente, promotions saisonnières qui redirigent vers des pages spéciales, ou équilibrage de charge entre serveurs.
Comment les clients doivent répondre à ce statut : Allez vers l’emplacement temporaire pour le moment, mais continuez à utiliser l’URL d’origine pour les demandes futures. Ne mettez pas à jour les signets ou les références permanentes.
Mauvais usages ou implémentations incorrectes : Utiliser 302 pour des déplacements permanents (utilisez 301 pour ceux-ci), créer des boucles de redirection où A envoie à B et B renvoie à A, ou utiliser 302 quand vous devez spécifiquement préserver la méthode HTTP (utilisez 307).
Mozilla.org Developer Doc pour référence supplémentaire
Qu’est-ce qu’un code d’état 303 ?
HTTP: 303 See Other
Quand et pourquoi les serveurs le retournent : Après avoir traité votre demande (généralement POST), le serveur veut que vous regardiez une page différente en utilisant GET. C’est comme soumettre un formulaire et être redirigé vers une page “merci”.
Cas d’utilisation pratiques : Après la soumission d’un formulaire, rediriger vers une page de confirmation ; après avoir effectué un paiement, rediriger vers un reçu ; chaque fois que vous voulez empêcher les soumissions en double lorsque les utilisateurs actualisent la page.
Comment les clients doivent répondre à ce statut : Faites une nouvelle demande GET vers la nouvelle URL. Cela empêche la resoumission accidentelle si les utilisateurs actualisent la page, puisque l’actualisation ne rechargera que la page finale, pas resoumission du formulaire.
Mauvais usages ou implémentations incorrectes : Utiliser 303 quand vous voulez préserver la méthode d’origine (utilisez 307), l’utiliser pour des redirections permanentes (utilisez 301), ou oublier que la redirection utilisera toujours GET quelle que soit la méthode d’origine.
Mozilla.org Developer Doc pour référence supplémentaire
Qu’est-ce qu’un code d’état 304 ?
HTTP: 304 Not Modified
Quand et pourquoi les serveurs le retournent : La ressource n’a pas changé depuis votre dernière demande, donc utilisez votre copie en cache. C’est comme vérifier si un document a été mis à jour et se faire dire “non, toujours le même”.
Cas d’utilisation pratiques : Mise en cache du navigateur où il vérifie si les fichiers images/CSS/JavaScript ont changé, réponses API qui changent rarement, ou toute situation où vous voulez économiser la bande passante en ne renvoyant pas de données inchangées.
Comment les clients doivent répondre à ce statut : Utilisez la version en cache que vous avez déjà. Aucune nouvelle donnée ne vient avec cette réponse - elle confirme juste que votre copie en cache est toujours bonne.
Mauvais usages ou implémentations incorrectes : Envoyer des données avec un 304 (il doit être vide), dire “non modifié” quand il a été réellement modifié, ou ne pas gérer correctement les en-têtes spéciaux qui font fonctionner cela.
Mozilla.org Developer Doc pour référence supplémentaire
Qu’est-ce qu’un code d’état 305 ?
HTTP: 305 Use Proxy
Quand et pourquoi les serveurs le retournent : Ce code d’état est obsolète et ne devrait jamais être utilisé. Il avait des problèmes de sécurité et a été abandonné par la communauté Web.
Cas d’utilisation pratiques : Aucun - ce code d’état est retiré et ne devrait pas être utilisé dans toute application moderne.
Comment les clients doivent répondre à ce statut : Les clients modernes devraient ignorer ce code d’état en raison de problèmes de sécurité. C’est un artefact historique.
Mauvais usages ou implémentations incorrectes : Utiliser ce code d’état du tout est une erreur. Il est obsolète pour de bonnes raisons de sécurité et ne devrait jamais apparaître dans les applications modernes.
Mozilla.org Developer Doc pour référence supplémentaire
Qu’est-ce qu’un code d’état 307 ?
HTTP: 307 Temporary Redirect
Quand et pourquoi les serveurs le retournent : Rediriger temporairement vers une autre URL, mais contrairement à 302, le client doit utiliser la même méthode. Si la demande d’origine était POST, la redirection doit aussi être POST.
Cas d’utilisation pratiques : Points de terminaison API en maintenance qui doivent préserver la méthode, équilibrage de charge qui maintient l’intégrité de la demande, ou toute redirection temporaire où changer de POST à GET casserait les choses.
Comment les clients doivent répondre à ce statut : Redirigez vers la nouvelle URL en utilisant exactement la même méthode et le même corps que la demande d’origine. C’est plus strict que les redirections 302.
Mauvais usages ou implémentations incorrectes : Utiliser 307 pour des déplacements permanents (utilisez 308), l’utiliser quand la préservation de la méthode n’a pas d’importance (302 est plus simple), ou ne pas réaliser que les clients doivent renvoyer le corps de la demande.
Mozilla.org Developer Doc pour référence supplémentaire
Qu’est-ce qu’un code d’état 308 ?
HTTP: 308 Permanent Redirect
Quand et pourquoi les serveurs le retournent : Comme 301, mais garantit que la méthode ne changera pas. Si vous avez POSTé vers l’ancienne URL, vous devez aussi POSTer vers la nouvelle URL.
Cas d’utilisation pratiques : Déplacement permanent de points de terminaison API qui acceptent POST/PUT/DELETE, restructuration de services RESTful tout en maintenant l’intégrité de la méthode, ou tout déplacement permanent où la méthode HTTP doit être préservée.
Comment les clients doivent répondre à ce statut : Mettez à jour de façon permanente les références pour utiliser la nouvelle URL, et utilisez toujours la même méthode HTTP que la demande d’origine lors de la redirection.
Mauvais usages ou implémentations incorrectes : Utiliser 308 pour des déplacements temporaires (utilisez 307), l’utiliser quand la préservation de la méthode n’a pas d’importance (301 est plus largement supporté), ou oublier que c’est un code d’état plus récent que les anciens clients pourraient ne pas comprendre.
Mozilla.org Developer Doc pour référence supplémentaire
Erreurs client 4xx
Ces codes indiquent que le client semble avoir fait une erreur.
Qu’est-ce qu’un code d’état 400 ?
HTTP: 400 Bad Request
Quand et pourquoi les serveurs le retournent : Votre demande est mal formée ou invalide d’une certaine manière. C’est comme remplir un formulaire avec votre email dans le champ du numéro de téléphone - le serveur ne peut pas le traiter parce que cela n’a pas de sens.
Cas d’utilisation pratiques : JSON invalide dans le corps de la demande, paramètres requis manquants, types de données incorrects (envoyer du texte quand un nombre est attendu), URL mal formées, ou toute erreur de syntaxe dans la demande.
Comment les clients doivent répondre à ce statut : Ne réessayez pas la même demande - elle échouera à nouveau. Corrigez d’abord le problème. Vérifiez le corps de la réponse pour les détails sur ce qui ne va pas et corrigez-le avant de réessayer.
Mauvais usages ou implémentations incorrectes : Utiliser 400 pour les problèmes d’authentification (utilisez 401), retourner 400 pour les erreurs serveur (utilisez 5xx), donner des messages d’erreur vagues qui n’aident pas à résoudre le problème, ou utiliser 400 comme fourre-tout pour toute erreur.
Mozilla.org Developer Doc pour référence supplémentaire
Qu’est-ce qu’un code d’état 401 ?
HTTP: 401 Unauthorized
Quand et pourquoi les serveurs le retournent : Vous devez vous connecter ou fournir des identifiants pour accéder à cette ressource. C’est comme essayer d’entrer dans une zone réservée aux membres sans montrer votre carte de membre.
Cas d’utilisation pratiques : Accès aux points de terminaison API protégés sans jeton, sessions de connexion expirées, clés API manquantes, ou toute demande à une ressource qui nécessite que vous prouviez qui vous êtes.
Comment les clients doivent répondre à ce statut : Invitez l’utilisateur à se connecter, redirigez vers une page de connexion, ou obtenez des identifiants valides avant de réessayer. Pour les API, obtenez un nouveau jeton d’authentification.
Mauvais usages ou implémentations incorrectes : Utiliser 401 quand les identifiants sont valides mais insuffisants (utilisez 403), oublier d’inclure des informations sur comment s’authentifier, ou confondre l’authentification (qui vous êtes) avec l’autorisation (ce que vous êtes autorisé à faire).
Mozilla.org Developer Doc pour référence supplémentaire
Qu’est-ce qu’un code d’état 403 ?
HTTP: 403 Forbidden
Quand et pourquoi les serveurs le retournent : Le serveur comprend qui vous êtes mais ne vous laissera pas accéder à cette ressource. C’est comme montrer votre pièce d’identité pour entrer dans une zone VIP mais se faire dire que vous n’êtes pas sur la liste.
Cas d’utilisation pratiques : Tentative d’accès aux fonctionnalités d’administration en tant qu’utilisateur régulier, tentative de voir les données privées d’un autre utilisateur, restrictions géographiques (contenu non disponible dans votre pays), ou blocage d’adresse IP.
Comment les clients doivent répondre à ce statut : Ne vous embêtez pas à réessayer avec les mêmes identifiants - ils ne fonctionneront pas. Affichez un message “accès refusé” et expliquez éventuellement comment obtenir un accès approprié si applicable.
Mauvais usages ou implémentations incorrectes : Utiliser 403 quand l’utilisateur n’est pas connecté (utilisez 401), utiliser 403 pour des ressources qui n’existent pas pour cacher leur existence (discutable - pourrait utiliser 404), ou ne pas être clair sur pourquoi l’accès est interdit.
Mozilla.org Developer Doc pour référence supplémentaire
Qu’est-ce qu’un code d’état 404 ?
HTTP: 404 Not Found
Quand et pourquoi les serveurs le retournent : Le serveur ne peut rien trouver à l’URL que vous avez demandée. C’est comme aller à une adresse de rue où il n’y a qu’un terrain vide - soit vous avez mal compris l’adresse, soit ce qui s’y trouvait est parti.
Cas d’utilisation pratiques : Taper une URL de manière incorrecte (comme gooogle.com au lieu de google.com), cliquer sur de vieux signets vers des pages qui ont été supprimées, suivre des liens brisés d’autres sites Web, faire des fautes de frappe dans les points de terminaison API, ou essayer d’accéder à des fichiers qui ont été déplacés ou renommés.
Comment les clients doivent répondre à ce statut : Affichez une page d’erreur qui aide les utilisateurs à comprendre quoi faire ensuite. Les bonnes pages 404 incluent une boîte de recherche, des liens vers des pages populaires, un moyen de signaler le lien brisé, ou même un message amusant pour rendre l’erreur moins frustrante.
Mauvais usages ou implémentations incorrectes : Utiliser 404 quand l’accès est refusé (utilisez 403 pour “vous ne pouvez pas voir ceci”), retourner 404 pour des choses qui ont été intentionnellement supprimées pour toujours (considérez 410 “Gone”), montrer des pages d’erreur génériques inutiles, ou utiliser 404 pour cacher que quelque chose existe aux utilisateurs non autorisés (bien que cela soit discutable pour la sécurité).
Mozilla.org Developer Doc pour référence supplémentaire
Qu’est-ce qu’un code d’état 405 ?
HTTP: 405 Method Not Allowed
Quand et pourquoi les serveurs le retournent : La ressource existe mais ne prend pas en charge la méthode HTTP que vous avez utilisée. C’est comme essayer de pousser une porte qui ne s’ouvre qu’en tirant - la porte existe, vous devez juste l’utiliser correctement.
Cas d’utilisation pratiques : Essayer de DELETE une ressource qui est en lecture seule, envoyer POST à un point de terminaison qui n’accepte que GET, tenter PUT sur des ressources qui ne peuvent pas être mises à jour, ou utiliser des méthodes personnalisées que le serveur ne prend pas en charge.
Comment les clients doivent répondre à ce statut : Vérifiez l’en-tête Allow pour voir quelles méthodes sont prises en charge, puis réessayez avec une méthode appropriée. Ne continuez pas à essayer la même méthode - elle n’est pas prise en charge.
Mauvais usages ou implémentations incorrectes : Ne pas inclure l’en-tête Allow requis listant les méthodes prises en charge, utiliser 405 quand la ressource n’existe pas (utilisez 404), ou retourner 405 pour des méthodes que le serveur devrait prendre en charge mais n’a pas encore implémentées (considérez 501).
Mozilla.org Developer Doc pour référence supplémentaire
Qu’est-ce qu’un code d’état 406 ?
HTTP: 406 Not Acceptable
Quand et pourquoi les serveurs le retournent : Le serveur ne peut pas fournir la ressource dans un format que vous accepterez. C’est comme demander un menu en français dans un restaurant qui n’a que des versions anglaises et espagnoles.
Cas d’utilisation pratiques : Demander du JSON à partir d’un point de terminaison qui ne fournit que du XML, demander un format d’image que le serveur ne prend pas en charge, échecs de négociation de langue, ou toute incompatibilité de négociation de contenu.
Comment les clients doivent répondre à ce statut : Modifiez vos en-têtes Accept pour demander un format que le serveur peut fournir, ou gérez les formats disponibles. La réponse peut lister les formats disponibles.
Mauvais usages ou implémentations incorrectes : Être trop strict sur les formats alors que vous pourriez fournir une valeur par défaut raisonnable, utiliser 406 pour des erreurs non liées à la négociation de contenu, ou ne pas indiquer clairement quels formats sont disponibles.
Mozilla.org Developer Doc pour référence supplémentaire
Qu’est-ce qu’un code d’état 407 ?
HTTP: 407 Proxy Authentication Required
Quand et pourquoi les serveurs le retournent : Un serveur proxy entre vous et la destination nécessite une authentification. C’est comme devoir montrer une pièce d’identité au gardien de sécurité avant même de pouvoir accéder au bâtiment que vous voulez entrer.
Cas d’utilisation pratiques : Serveurs proxy d’entreprise nécessitant une connexion employé, passerelles réseau nécessitant une authentification, services proxy payants nécessitant des identifiants, ou toute configuration de proxy authentifié.
Comment les clients doivent répondre à ce statut : Authentifiez-vous auprès du serveur proxy (pas du serveur de destination) en utilisant la méthode spécifiée dans l’en-tête Proxy-Authenticate, puis réessayez la demande d’origine.
Mauvais usages ou implémentations incorrectes : Confondre ceci avec l’authentification 401 régulière, ne pas inclure l’en-tête Proxy-Authenticate, ou utiliser 407 quand c’est le serveur de destination (pas le proxy) qui nécessite l’authentification.
Mozilla.org Developer Doc pour référence supplémentaire
Qu’est-ce qu’un code d’état 408 ?
HTTP: 408 Request Timeout
Quand et pourquoi les serveurs le retournent : Le serveur a attendu que vous envoyiez la demande complète, mais vous avez pris trop de temps. C’est comme commencer à commander dans un restaurant mais faire une pause si longtemps que le serveur s’en va.
Cas d’utilisation pratiques : Connexions réseau lentes causant des retards, téléchargements de fichiers volumineux sur de mauvaises connexions, applications client qui se figent pendant la transmission de la demande, ou interruptions réseau lors de l’envoi de données.
Comment les clients doivent répondre à ce statut : Vous pouvez réessayer la demande, de préférence avec une meilleure connexion ou une charge utile plus petite. Considérez la division des grandes demandes en morceaux plus petits ou l’amélioration des conditions réseau.
Mauvais usages ou implémentations incorrectes : Utiliser 408 quand le serveur est lent (c’est 504), définir des délais d’attente déraisonnablement courts, ou utiliser 408 pour des délais d’attente au niveau de l’application plutôt qu’au niveau du réseau.
Mozilla.org Developer Doc pour référence supplémentaire
Qu’est-ce qu’un code d’état 409 ?
HTTP: 409 Conflict
Quand et pourquoi les serveurs le retournent : Votre demande est en conflit avec l’état actuel de la ressource. C’est comme essayer de créer un nom d’utilisateur qui est déjà pris - l’opération a du sens, mais elle ne peut pas être faite maintenant.
Cas d’utilisation pratiques : Essayer de créer un enregistrement en double, éditer un document que quelqu’un d’autre est en train d’éditer, conflits de version dans les systèmes collaboratifs, ou violation de règles métier (comme réserver doublement une ressource).
Comment les clients doivent répondre à ce statut : Résolvez le conflit en choisissant une valeur différente, en fusionnant les modifications, ou en attendant que le conflit se résolve. La réponse devrait expliquer quel est le conflit et comment le résoudre.
Mauvais usages ou implémentations incorrectes : Utiliser 409 pour les erreurs de validation (considérez 422), ne pas expliquer comment résoudre le conflit, utiliser 409 pour les problèmes de permission (utilisez 403), ou signaler des conflits qui ne sont pas réellement résolvables par le client.
Mozilla.org Developer Doc pour référence supplémentaire
Qu’est-ce qu’un code d’état 410 ?
HTTP: 410 Gone
Quand et pourquoi les serveurs le retournent : La ressource existait ici mais a été délibérément supprimée et ne reviendra pas. C’est comme visiter un bâtiment démoli - ce n’est pas juste temporairement fermé, c’est définitivement parti.
Cas d’utilisation pratiques : Articles ou publications qui ont été supprimés pour violations de politique, produits qui sont définitivement abandonnés, anciennes versions d’API qui ont été retirées, ou tout contenu intentionnellement et définitivement supprimé.
Comment les clients doivent répondre à ce statut : Supprimez les signets, mettez à jour les liens, et informez les utilisateurs que le contenu est définitivement parti. Les moteurs de recherche devraient supprimer ces URL de leur index. Ne continuez pas à vérifier - ça ne reviendra pas.
Mauvais usages ou implémentations incorrectes : Utiliser 410 pour des suppressions temporaires (utilisez 503), utiliser 410 quand vous pourriez restaurer le contenu, utiliser 410 pour des choses qui n’ont jamais existé (utilisez 404), ou ne pas être certain que la suppression est permanente.
Mozilla.org Developer Doc pour référence supplémentaire
Qu’est-ce qu’un code d’état 418 ?
HTTP: 418 I’m a teapot
Quand et pourquoi les serveurs le retournent : C’est un code d’état blague d’un RFC du poisson d’avril sur le contrôle des cafetières. Cela signifie “Je suis une théière, et vous m’avez demandé de faire du café, ce que je ne peux pas faire.”
Cas d’utilisation pratiques : Œufs de Pâques dans les applications, démonstration de l’extensibilité de HTTP dans les cours de programmation, ajout d’humour aux environnements de développement/test, ou comme réponse ludique dans des contextes appropriés.
Comment les clients doivent répondre à ce statut : Reconnaissez-le comme une réponse humoristique et gérez-le de manière appropriée - peut-être afficher un message d’erreur amusant ou des images liées au thé. Ne vous attendez pas à cela dans des environnements de production sérieux.
Mauvais usages ou implémentations incorrectes : Utiliser 418 pour des erreurs réelles dans les systèmes de production, l’utiliser excessivement au point d’être ennuyeux, ou le retourner aux utilisateurs qui ne comprendront pas la blague.
Mozilla.org Developer Doc pour référence supplémentaire
Qu’est-ce qu’un code d’état 422 ?
HTTP: 422 Unprocessable Entity
Quand et pourquoi les serveurs le retournent : Le format de votre demande est correct, mais le contenu n’a pas de sens. C’est comme remplir un formulaire correctement mais entrer des données impossibles - comme avoir 300 ans ou être né dans le futur.
Cas d’utilisation pratiques : Échecs de validation de formulaire (email sans symbole @), violations de règles métier (date de fin avant la date de début), erreurs sémantiques dans les demandes API, ou toute erreur logique dans des données correctement formatées.
Comment les clients doivent répondre à ce statut : Lisez les détails d’erreur pour comprendre quelle validation a échoué, corrigez les données pour répondre aux exigences, et resoumettez. La structure était correcte ; le contenu nécessite un ajustement.
Mauvais usages ou implémentations incorrectes : Utiliser 422 pour les erreurs de syntaxe (utilisez 400), ne pas fournir de détails d’erreur de validation spécifiques, utiliser 422 pour les problèmes d’authentification/autorisation, ou être incohérent sur ce qui déclenche 422 vs 400.
Mozilla.org Developer Doc pour référence supplémentaire
Qu’est-ce qu’un code d’état 429 ?
HTTP: 429 Too Many Requests
Quand et pourquoi les serveurs le retournent : Vous envoyez trop de demandes trop rapidement. C’est comme appeler quelqu’un à plusieurs reprises - finalement, ils arrêteront de répondre et vous diront de ralentir.
Cas d’utilisation pratiques : Limitation de taux d’API (par exemple, 100 demandes par heure), prévention d’abus ou d’attaques DDoS, protection des serveurs contre la surcharge, ou application de politiques d’utilisation équitable.
Comment les clients doivent répondre à ce statut : Arrêtez de faire des demandes et attendez. Vérifiez l’en-tête Retry-After pour voir quand vous pouvez réessayer. Implémentez un backoff exponentiel - attendez plus longtemps entre chaque tentative de réessai.
Mauvais usages ou implémentations incorrectes : Ne pas inclure l’en-tête Retry-After pour guider les clients, définir des limites trop basses pour une utilisation normale, utiliser 429 pour d’autres types de surcharge (considérez 503), ou ne pas documenter clairement les limites de taux.
Mozilla.org Developer Doc pour référence supplémentaire
Qu’est-ce qu’un code d’état 451 ?
HTTP: 451 Unavailable For Legal Reasons
Quand et pourquoi les serveurs le retournent : Le contenu est bloqué en raison d’exigences légales. Nommé d’après “Fahrenheit 451” de Ray Bradbury sur la censure, ce statut indique un blocage gouvernemental ou légal.
Cas d’utilisation pratiques : Contenu bloqué par ordonnance du tribunal, avis de retrait DMCA, restrictions géographiques dues aux lois locales, exigences de censure gouvernementale, ou tout blocage de contenu légalement mandaté.
Comment les clients doivent répondre à ce statut : Informez les utilisateurs que le contenu est légalement restreint. La réponse peut inclure des détails sur qui a demandé le blocage (si cela est légalement autorisé à partager).
Mauvais usages ou implémentations incorrectes : Utiliser 451 pour des blocages non légaux (utilisez le code 4xx approprié), ne pas être transparent sur les blocages légaux lorsque c’est possible, ou utiliser 451 pour des politiques de contenu volontaires plutôt que des exigences légales.
Mozilla.org Developer Doc pour référence supplémentaire
Erreurs serveur 5xx
Ces codes indiquent que le serveur n’a pas réussi à répondre à une demande valide.
Qu’est-ce qu’un code d’état 500 ?
HTTP: 500 Internal Server Error
Quand et pourquoi les serveurs le retournent : Quelque chose s’est mal passé du côté du serveur, et il ne sait pas comment le gérer. C’est comme une caisse enregistreuse qui plante dans un magasin - le problème n’est pas avec votre mode de paiement, leur système s’est juste cassé.
Cas d’utilisation pratiques : Lorsque la connexion à la base de données échoue, lorsqu’il y a un bug dans le code du serveur, lorsque le serveur manque de mémoire, ou tout plantage inattendu que les programmeurs n’ont pas anticipé.
Comment les clients doivent répondre à ce statut : Dites aux utilisateurs que quelque chose s’est mal passé et suggérez de réessayer plus tard. Vous pourriez automatiquement réessayer après un délai, puisque ces erreurs sont souvent temporaires.
Mauvais usages ou implémentations incorrectes : Utiliser 500 pour les erreurs utilisateur (utilisez les codes 4xx pour ceux-ci), montrer des messages d’erreur détaillés aux utilisateurs (risque de sécurité !), ne pas enregistrer suffisamment de détails pour corriger le problème, ou utiliser 500 comme fourre-tout paresseux pour toute erreur.
Mozilla.org Developer Doc pour référence supplémentaire
Qu’est-ce qu’un code d’état 501 ?
HTTP: 501 Not Implemented
Quand et pourquoi les serveurs le retournent : Le serveur ne prend pas en charge la fonctionnalité que vous demandez. C’est comme demander à une calculatrice de base de tracer des fonctions - elle comprend ce que vous voulez mais n’a pas cette fonctionnalité.
Cas d’utilisation pratiques : Utilisation de méthodes HTTP que le serveur ne reconnaît pas, demande de fonctionnalités qui sont prévues mais pas encore construites, serveurs hérités qui ne prennent pas en charge les fonctionnalités modernes, ou méthodes personnalisées qui ne sont pas implémentées.
Comment les clients doivent répondre à ce statut : Ne réessayez pas cette demande - le serveur ne peut pas la gérer. Utilisez une approche différente ou vérifiez s’il existe un moyen alternatif d’obtenir ce dont vous avez besoin.
Mauvais usages ou implémentations incorrectes : Utiliser 501 pour des fonctionnalités temporairement désactivées (utilisez 503), utiliser 501 pour des méthodes que vous reconnaissez mais n’autorisez pas (utilisez 405), ou utiliser 501 comme excuse pour des fonctionnalités manquantes qui devraient être implémentées.
Mozilla.org Developer Doc pour référence supplémentaire
Qu’est-ce qu’un code d’état 502 ?
HTTP: 502 Bad Gateway
Quand et pourquoi les serveurs le retournent : Un serveur agissant comme passerelle ou proxy a reçu une réponse invalide d’un serveur en amont. C’est comme demander à quelqu’un de relayer un message, mais ils reviennent en disant “la personne que j’ai demandée m’a donné du charabia”.
Cas d’utilisation pratiques : L’équilibreur de charge ne peut pas atteindre les serveurs backend, la passerelle API reçoit des erreurs des microservices, le proxy inverse obtient des réponses mal formées, ou le CDN incapable de récupérer du serveur d’origine.
Comment les clients doivent répondre à ce statut : C’est généralement temporaire, alors réessayez après un court délai. Le problème est entre les serveurs, pas avec votre demande, donc réessayer pourrait fonctionner une fois qu’ils ont résolu leurs problèmes de communication.
Mauvais usages ou implémentations incorrectes : Utiliser 502 pour les propres erreurs du serveur d’origine (utilisez 500), ne pas distinguer entre les scénarios “ne peut pas atteindre” et “réponse invalide”, ou utiliser 502 quand la passerelle elle-même a des problèmes.
Mozilla.org Developer Doc pour référence supplémentaire
Qu’est-ce qu’un code d’état 503 ?
HTTP: 503 Service Unavailable
Quand et pourquoi les serveurs le retournent : Le serveur est temporairement incapable de gérer les demandes. C’est comme un magasin mettant une pancarte “fermé pour maintenance” - ils reviendront, mais pas tout de suite.
Cas d’utilisation pratiques : Fenêtres de maintenance planifiées, situations de surcharge du serveur, pannes temporaires pour les mises à jour, limitation de taux au niveau du serveur, ou toute incapacité temporaire de servir les demandes.
Comment les clients doivent répondre à ce statut : Attendez et réessayez plus tard. Vérifiez l’en-tête Retry-After pour des conseils sur quand revenir. Implémentez un backoff exponentiel pour les réessais afin d’éviter de submerger le serveur lors de son retour.
Mauvais usages ou implémentations incorrectes : Utiliser 503 pour des problèmes permanents (utilisez l’erreur appropriée), ne pas inclure Retry-After quand vous savez combien de temps cela prendra, utiliser 503 pour des problèmes spécifiques au client plutôt que des problèmes à l’échelle du serveur.
Mozilla.org Developer Doc pour référence supplémentaire
Qu’est-ce qu’un code d’état 504 ?
HTTP: 504 Gateway Timeout
Quand et pourquoi les serveurs le retournent : Un serveur agissant comme passerelle ou proxy n’a pas reçu de réponse en temps opportun d’un serveur en amont. C’est comme demander à quelqu’un de relayer un message, mais ils reviennent en disant “J’ai attendu et attendu, mais ils n’ont jamais répondu”.
Cas d’utilisation pratiques : Requêtes de base de données prenant trop de temps, services backend surchargés, problèmes réseau entre serveurs, microservices ne répondant pas assez rapidement, ou tout délai d’attente dans la communication serveur à serveur.
Comment les clients doivent répondre à ce statut : Vous pouvez réessayer, mais soyez conscient que l’opération pourrait être coûteuse ou lente. Considérez si la demande est suffisamment critique pour réessayer, et implémentez des limites de réessai raisonnables.
Mauvais usages ou implémentations incorrectes : Utiliser 504 quand les clients sont lents (utilisez 408), définir des délais d’attente trop courts pour les opérations raisonnables, ne pas distinguer entre différents scénarios de délai d’attente, ou utiliser 504 pour les propres délais d’attente du serveur d’origine.
Mozilla.org Developer Doc pour référence supplémentaire
Qu’est-ce qu’un code d’état 505 ?
HTTP: 505 HTTP Version Not Supported
Quand et pourquoi les serveurs le retournent : Le serveur ne prend pas en charge la version HTTP utilisée dans la demande. C’est comme essayer de lire un disque Blu-ray dans un lecteur DVD - le lecteur comprend ce que vous voulez mais ne peut pas gérer ce format.
Cas d’utilisation pratiques : Anciens serveurs qui ne prennent en charge que HTTP/1.0 recevant des demandes HTTP/2, serveurs pas encore mis à niveau pour prendre en charge les versions HTTP plus récentes, ou versions HTTP personnalisées/expérimentales que le serveur ne reconnaît pas.
Comment les clients doivent répondre à ce statut : Réessayez la demande en utilisant une version HTTP différente, typiquement en revenant à HTTP/1.1 qui est universellement pris en charge. Vérifiez quelles versions le serveur prend en charge.
Mauvais usages ou implémentations incorrectes : Utiliser 505 pour des fonctionnalités non prises en charge au sein d’une version (utilisez 501), ne pas essayer de gérer la négociation de version avec élégance, ou rejeter des versions HTTP standard qui devraient être prises en charge.
Mozilla.org Developer Doc pour référence supplémentaire
Qu’est-ce qu’un code d’état 507 ?
HTTP: 507 Insufficient Storage
Quand et pourquoi les serveurs le retournent : Le serveur n’a pas suffisamment d’espace de stockage pour compléter la demande. C’est comme essayer d’enregistrer un fichier quand le disque dur est plein.
Cas d’utilisation pratiques : Échecs de téléchargement de fichiers dus à un disque plein, opérations de base de données atteignant les quotas de stockage, opérations WebDAV dépassant l’espace alloué, ou toute opération nécessitant plus de stockage que disponible.
Comment les clients doivent répondre à ce statut : Informez les utilisateurs des limites de stockage. Pourrait nécessiter de supprimer l’ancien contenu, demander plus de stockage, ou réduire la taille de ce que vous essayez de stocker.
Mauvais usages ou implémentations incorrectes : Utiliser 507 pour des problèmes de stockage temporaires qui se résoudront (considérez 503), ne pas surveiller correctement le stockage, utiliser 507 pour des problèmes de quota non liés au stockage physique, ou ne pas fournir d’informations sur les limites de stockage.
Mozilla.org Developer Doc pour référence supplémentaire
Qu’est-ce qu’un code d’état 508 ?
HTTP: 508 Loop Detected
Quand et pourquoi les serveurs le retournent : Le serveur a détecté une boucle infinie lors du traitement de la demande. C’est comme suivre des directions qui disent “voir l’étape 1” à la fin - vous tourneriez en rond pour toujours.
Cas d’utilisation pratiques : Opérations WebDAV avec des références circulaires, chaînes de redirection qui bouclent sur elles-mêmes, liens symboliques qui créent des cycles, ou toute opération serveur qui détecte qu’elle se répète sans fin.
Comment les clients doivent répondre à ce statut : Ne réessayez pas la même demande - elle atteindra la même boucle. Vérifiez les références circulaires dans votre structure de données et corrigez-les avant de réessayer.
Mauvais usages ou implémentations incorrectes : Utiliser 508 pour des erreurs non liées aux boucles, ne pas implémenter une détection de boucle appropriée, utiliser 508 pour les boucles de redirection côté client (celles apparaissent différemment), ou détecter des faux positifs comme des boucles.
Mozilla.org Developer Doc pour référence supplémentaire
Qu’est-ce qu’un code d’état 511 ?
HTTP: 511 Network Authentication Required
Quand et pourquoi les serveurs le retournent : Vous devez vous authentifier auprès du réseau lui-même avant de pouvoir accéder à Internet. C’est comme devoir se connecter au WiFi de l’hôtel avant de pouvoir naviguer sur les sites Web.
Cas d’utilisation pratiques : Pages de connexion WiFi d’hôtel ou d’aéroport, portails d’accès réseau d’entreprise, WiFi public nécessitant d’accepter les conditions d’utilisation, ou toute situation de portail captif.
Comment les clients doivent répondre à ce statut : Redirigez les utilisateurs vers la page de connexion réseau (généralement fournie dans la réponse). Une fois qu’ils s’authentifient auprès du réseau, ils peuvent réessayer leur demande d’origine.
Mauvais usages ou implémentations incorrectes : Utiliser 511 pour les exigences de connexion au site Web (utilisez 401), utiliser 511 pour l’authentification proxy (utilisez 407), ou implémenter des portails captifs de manières qui cassent les connexions sécurisées.
Mozilla.org Developer Doc pour référence supplémentaire