Les codes HTTP 4xx (401, 402 et 403, 404, 41, 429…) , appartiennent à la catégorie des codes de réponse client, indiquant généralement des erreurs ou des problèmes rencontrés du côté du client (c’est-à-dire du navigateur web ou de l’application cliente). Voici ce qu’ils signifient généralement :
Code HTTP 400 Bad Request
Le code HTTP 400, également connu sous le nom de « Bad Request », est une réponse standard du serveur indiquant qu’il n’a pas pu comprendre ou traiter la requête envoyée par le client, généralement en raison d’une anomalie dans la syntaxe de la requête.
Voici quelques explications supplémentaires :
- Anomalie dans la syntaxe de la requête : Il est possible que la structure de la requête HTTP ne soit pas correcte, ce qui empêche le serveur de la comprendre et de la traiter.
- URL Incorrecte : L’URL que le client tente d’atteindre peut être incorrecte ou malformée.
- Taille de la Requête trop Grande : La requête envoyée au serveur peut être trop volumineuse pour être traitée.
- Problèmes avec les En-têtes de la Requête (Headers) : Les en-têtes de la requête peuvent contenir des valeurs invalides ou être formatées incorrectement.
- Cookies Invalides : Les cookies envoyés avec la requête peuvent être invalides ou corrompus, provoquant une erreur 400.
- Problèmes de Codage de Caractères : La requête peut contenir des caractères qui ne sont pas correctement encodés.
Comment résoudre une erreur 400 ?
Il est souvent nécessaire de vérifier la syntaxe de la requête, les URL, les en-têtes, et autres composants pour s’assurer qu’ils sont formatés correctement. Dans le contexte d’un navigateur web, cela peut aussi impliquer de vider les cookies et le cache du navigateur pour résoudre les problèmes potentiels liés aux cookies invalides ou corrompus.
Code HTTP 401 Unauthorized
Le code HTTP 401, qui signifie « Unauthorized » (non autorisé), indique qu’une requête n’a pas été exécutée car elle nécessite une authentification utilisateur valide. En d’autres termes, l’utilisateur doit fournir des identifiants corrects (comme un nom d’utilisateur et un mot de passe) pour accéder à la ressource demandée.
Quand un serveur renvoie un code 401, il inclut généralement un champ WWW-Authenticate dans l’en-tête de la réponse, indiquant le type d’authentification requis pour accéder à la ressource.
Par exemple, si vous essayez d’accéder à une page Web ou une API qui nécessite une connexion et que vous n’êtes pas connecté ou que vous fournissez des identifiants incorrects, le serveur peut renvoyer une réponse avec un code d’état HTTP 401.
Code HTTP 402 Payment Required
Le code HTTP 402 « Payment Required » est une valeur de code de statut HTTP qui n’est pas utilisée de manière standard. Selon la spécification initiale, ce code devait être utilisé pour indiquer qu’un client doit payer pour accéder à une ressource. Cependant, ce code n’a jamais été adopté de manière conventionnelle et n’est généralement pas utilisé dans la pratique courante.
Cela dit, il est théoriquement possible que certains serveurs ou applications web l’utilisent dans un contexte spécifique, implémentant par exemple un mécanisme propre à un site ou à une application pour gérer les transactions financières ou les accès payants à certaines ressources. Dans ce cas, le comportement exact associé à ce code dépendrait de l’implémentation spécifique du serveur ou de l’application.
Code HTTP 403 Forbidden
Un code HTTP 403 Forbidden est un code d’état HTTP standard qui est retourné par un serveur pour indiquer qu’il a compris la requête envoyée par le client (par exemple, un navigateur web), mais l’accès à la ressource demandée est refusé. En d’autres termes, le serveur a compris la requête, mais il refuse de l’autoriser.
Ce code est souvent retourné dans les cas suivants :
- Permissions insuffisantes : L’utilisateur qui tente d’accéder à la ressource n’a pas les permissions nécessaires pour y accéder.
- Contenu protégé par mot de passe : La ressource est protégée par un mot de passe et l’utilisateur n’a pas fourni les identifiants corrects.
- IP bannie : L’adresse IP de l’utilisateur est peut-être bannie, l’empêchant d’accéder à la ressource.
- Erreurs de configuration du serveur : Il peut y avoir une erreur de configuration du serveur qui empêche l’accès à certaines ressources.
Dans la plupart des cas, si un utilisateur reçoit un code d’état 403, il n’y a rien qu’il puisse faire pour résoudre le problème, car l’accès est contrôlé par le propriétaire du site web. Cependant, si vous êtes le propriétaire du site web, vous devrez peut-être ajuster les permissions ou les configurations de votre serveur pour résoudre le problème.
Code HTTP 404 Not Found
Le code HTTP 404, ou « 404 Not Found », est un code d’état standard dans le protocole HTTP qui indique que le serveur n’a pas pu trouver la ressource demandée. En d’autres termes, le serveur est fonctionnel et capable de communiquer, mais la ressource spécifique (comme une page web) que vous cherchez n’existe pas ou n’a pas pu être trouvée.
Voici un détail plus approfondi sur ce que signifie ce code:
- Ressource Inexistante : Le code 404 est souvent renvoyé lorsqu’une page a été supprimée ou déplacée et que l’URL n’est plus valide.
- Erreur de Frappe : Si une URL est incorrectement saisie dans la barre d’adresse du navigateur, cela peut également déclencher une erreur 404.
- Lien Cassé : Un lien qui pointe vers une ressource qui n’existe plus peut également entraîner une erreur 404.
- Problèmes de Configuration du Serveur : Parfois, une configuration incorrecte du serveur peut faire en sorte qu’une ressource qui existe réellement renvoie une erreur 404.
- SEO et Expérience Utilisateur : Les erreurs 404 peuvent avoir un impact négatif sur le SEO (optimisation pour les moteurs de recherche) et l’expérience utilisateur, car elles peuvent conduire à des impasses pour les utilisateurs et les robots d’indexation des moteurs de recherche.
Comment corriger les erreurs 404 ?
Les propriétaires de sites web doivent s’assurer que toutes les URL sont correctement formées, que les liens sont à jour et que les redirections sont en place pour les ressources qui ont été déplacées ou renommées. Ils peuvent également mettre en place des pages d’erreur 404 personnalisées qui aident les utilisateurs à trouver ce qu’ils cherchent, même si la ressource originale n’est pas disponible.
Code HTTP 405 Method Not Allowed
Le code d’état HTTP 405, également connu sous le nom « Method Not Allowed », signifie qu’un client web a tenté d’accéder à une ressource sur un serveur web en utilisant une méthode HTTP que le serveur ne supporte pas pour cette ressource particulière. Les méthodes HTTP typiques sont GET, POST, PUT, DELETE, etc.
Par exemple, si une ressource sur un serveur web est configurée pour n’accepter que les requêtes GET et POST, et qu’un client tente d’effectuer une requête PUT sur cette ressource, le serveur renverra une réponse avec un code d’état 405.
Voici une brève description des principales méthodes HTTP pour référence :
- GET : Utilisée pour récupérer des informations à partir du serveur.
- POST : Utilisée pour envoyer de nouvelles informations au serveur.
- PUT : Utilisée pour mettre à jour des informations existantes sur le serveur.
- DELETE : Utilisée pour supprimer des informations du serveur.
- HEAD : Utilisée pour récupérer les en-têtes HTTP d’une ressource.
- OPTIONS : Utilisée pour récupérer les méthodes HTTP supportées par une ressource.
Lorsque vous recevez une erreur 405, cela suggère que vous devriez vérifier si vous utilisez la bonne méthode HTTP pour la ressource que vous tentez d’accéder, ou vérifier si l’URL est correcte.
Code HTTP 406 Not Acceptable
Le code de statut HTTP 406 « Not Acceptable » est une réponse standard du protocole HTTP qui indique que le serveur ne peut produire une réponse correspondant à la liste des formats acceptables définie dans la requête du client, généralement spécifiée par les en-têtes « Accept » dans la requête HTTP. En d’autres termes, le serveur ne peut pas répondre avec le type de contenu que le client a demandé.
Dans une requête HTTP, le client peut spécifier les types de contenu qu’il accepte à l’aide des en-têtes « Accept », « Accept-Encoding », « Accept-Language » et « Accept-Charset ». Le serveur utilise ces en-têtes pour déterminer comment formater la réponse. Si le serveur ne peut pas produire une réponse dans un format que le client accepte, il renverra le code d’état 406.
Par exemple, si un client envoie une requête HTTP avec un en-tête « Accept » spécifiant uniquement « application/json », mais que le serveur ne peut générer qu’une réponse « text/html », le serveur renverra une réponse 406 « Not Acceptable ».
Code HTTP 407 Proxy Authentication Required
Le code HTTP 407 « Proxy Authentication Required » signifie que le client doit d’abord s’authentifier auprès du serveur proxy avant que celui-ci n’autorise la requête à atteindre le serveur final. En d’autres termes, le serveur proxy nécessite une sorte de connexion ou de validation avant de permettre au client de communiquer avec le serveur web.
Voici comment cela fonctionne en détail:
- Client : Effectue une requête HTTP pour accéder à une certaine ressource sur le web.
- Serveur Proxy : Intercepte la requête et envoie une réponse avec le code d’état 407, demandant une authentification.
- Client : Reçoit la réponse 407 et renvoie une nouvelle requête avec les informations d’authentification nécessaires (souvent sous forme d’en-têtes Proxy-Authorization contenant les détails d’authentification).
- Serveur Proxy : Vérifie les informations d’authentification et, si elles sont correctes, autorise la requête à atteindre le serveur web destination.
- Serveur Web (si l’étape 4 est réussie) : Traite la requête et envoie une réponse au client via le serveur proxy.
Comment résoudre une erreur 407 ?
Vous devrez généralement fournir les informations d’authentification appropriées pour le proxy, ce qui peut impliquer de configurer ces informations dans les paramètres de votre navigateur web ou dans les paramètres de configuration de l’application que vous utilisez pour faire la requête HTTP.
Code HTTP 408 Request Time-out
Le code HTTP 408 « Request Timeout » est une réponse standard du protocole HTTP qui indique que le serveur n’a pas reçu de réponse complète de la part du client dans un délai imparti.
Voici quelques points à considérer à propos de cette erreur :
- Délai d’attente : L’erreur se produit lorsque le serveur attend trop longtemps pour recevoir une requête du client. Le temps d’attente peut être défini par le serveur, et s’il n’y a pas de communication du client pendant cette période, l’erreur 408 peut être déclenchée.
- Problèmes de connexion : Cette erreur peut être due à des problèmes de connexion réseau qui empêchent le client d’envoyer une requête complète dans les temps.
- Serveur surchargé : Parfois, si le serveur est surchargé, il peut ne pas être en mesure de traiter les requêtes dans le délai imparti, ce qui peut également conduire à une erreur 408.
- Problèmes côté client : L’erreur peut également être due à des problèmes du côté client, comme des problèmes de connexion Internet, un navigateur web défectueux ou des problèmes avec l’appareil du client.
Pour résoudre cette erreur 408, voici quelques étapes que vous pouvez essayer :
- Vérifier la connexion Internet : Assurez-vous que votre connexion Internet est stable et fonctionne correctement.
- Réessayer la requête : Parfois, simplement réessayer la requête peut résoudre le problème, car il peut s’agir d’un problème temporaire.
- Vérifier l’URL : Assurez-vous que l’URL que vous essayez d’atteindre est correcte et complète.
- Contactez le support technique du site web : Si l’erreur persiste, vous pourriez vouloir contacter le support technique du site web pour les informer du problème.
- Vérifiez les paramètres du navigateur : Si possible, essayez d’accéder au site web à partir d’un autre navigateur pour voir si le problème persiste.
- Mise à jour des systèmes : Assurez-vous que votre navigateur ou votre application est à jour, car les versions obsolètes peuvent parfois causer ce type d’erreurs.
Code HTTP 409 Conflict
Le code d’état HTTP 409, intitulé « Conflict », indique qu’une requête ne peut être complétée en raison d’un conflit avec l’état actuel de la ressource ciblée. Ce statut est souvent utilisé dans les situations où il est nécessaire de modifier une ressource existante, mais la modification ne peut pas être effectuée en raison d’un conflit avec les modifications existantes (par exemple, lors de mises à jour simultanées par plusieurs clients).
Lorsqu’une réponse contient un code 409, elle devrait également inclure des informations suffisantes pour que le client comprenne la nature du conflit et sache comment le résoudre, éventuellement avec des informations détaillées sur les différences spécifiques entre l’état actuel de la ressource et l’état demandé dans la requête.
Voici un exemple simple de situation où un code 409 pourrait être utilisé :
- Utilisateur A et Utilisateur B chargent tous deux une ressource (par exemple, un document) à partir d’un serveur.
- Utilisateur A modifie la ressource et la renvoie au serveur, où elle est mise à jour.
- Peu de temps après, l’Utilisateur B essaie également de mettre à jour la ressource, en utilisant la version originale du document comme base. Étant donné que la version du document sur le serveur a changé depuis que l’utilisateur B l’a chargée, le serveur renvoie un code d’état 409 pour indiquer que la mise à jour ne peut pas être effectuée en raison d’un conflit.
Dans ce cas, l’Utilisateur B doit généralement recharger la ressource à partir du serveur pour obtenir la version la plus récente, apporter les modifications souhaitées à cette nouvelle version, puis essayer de la renvoyer au serveur.
Code HTTP 410 Gone
Un code d’état HTTP 410, également connu sous le nom de « 410 Gone », est une réponse du serveur qui indique que la ressource demandée a été supprimée de façon permanente et ne sera plus disponible à l’avenir. Autrement dit, le serveur sait que la ressource existait autrefois, mais elle a été retirée et il n’y a pas de redirection vers une nouvelle URL.
Cela contraste avec un code 404, qui indique que la ressource n’a pas été trouvée mais pourrait potentiellement être disponible à nouveau à l’avenir. Le code 410 est plus définitif, indiquant que la ressource a été délibérément supprimée et ne sera pas restaurée.
Code HTTP 411 Length Required
Le code d’état HTTP 411, « Length Required », est une réponse standard du protocole HTTP indiquant qu’une requête ne peut être traitée car elle manque d’un en-tête « Content-Length », qui est requis par le serveur pour traiter la requête. Cette réponse est généralement renvoyée par le serveur lorsque la méthode de requête exige un corps de message (comme POST ou PUT) mais que l’en-tête « Content-Length » n’est pas présent ou n’est pas correctement spécifié.
Pour résoudre ce problème, vous pouvez ajouter un en-tête « Content-Length » approprié à la requête, avec la longueur correcte du corps de message.
Voici un exemple de ce à quoi cela pourrait ressembler dans une requête HTTP :
POST /chemin/ressource HTTP/1.1
Host: www.exemple.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 123
param1=valeur1¶m2=valeur2
Dans cet exemple, l’en-tête « Content-Length » indique que la longueur du corps de message est de 123 octets.
Code HTTP 412 Precondition Failed
Le code d’état HTTP 412 Precondition Failed est une réponse du serveur indiquant qu’une des préconditions envoyées par le client (par exemple, l’un des en-têtes de la requête) n’a pas été satisfaite. Ce code d’état fait partie de la standardisation des codes d’état HTTP qui sont définis dans les spécifications du protocole HTTP.
Voici quelques points pour mieux comprendre ce code d’état :
Préconditions : Les préconditions sont généralement définies dans les en-têtes HTTP d’une requête. Par exemple, l’en-tête If-Match, If-Modified-Since, If-None-Match, If-Unmodified-Since ou If-Range.
Utilisation : Ce code d’état est utilisé pour garantir l’intégrité des données et prévenir les conflits lors de la mise à jour des ressources. Il est souvent utilisé dans des systèmes où il est crucial de s’assurer que les modifications ne sont apportées que sous certaines conditions.
Exemple de cas d’utilisation : Imaginons que vous vouliez mettre à jour une ressource seulement si elle n’a pas été modifiée depuis votre dernier accès. Vous pouvez envoyer une requête avec un en-tête If-Modified-Since avec la date de votre dernier accès. Si la ressource a été modifiée depuis cette date, le serveur répondra avec un 412 Precondition Failed, indiquant que la mise à jour ne peut pas être effectuée car la précondition n’a pas été satisfaite.
Gestion des erreurs : Lorsqu’un client reçoit une réponse 412, il doit généralement reconsidérer son action, peut-être en récupérant à nouveau la ressource pour vérifier son état actuel avant de tenter à nouveau l’opération.
Voici un exemple hypothétique d’une requête HTTP qui pourrait recevoir une réponse 412 :
PUT /resource/1234 HTTP/1.1
Host: www.exemple.com
If-Unmodified-Since: Wed, 21 Oct 2015 07:28:00 GMT
(données de la requête...)
Et une réponse possible du serveur :
HTTP/1.1 412 Precondition Failed
Content-Type: text/html
(corps de la réponse...)
Dans cet exemple, la requête PUT échoue parce que la ressource a été modifiée depuis la date spécifiée dans l’en-tête « If-Unmodified-Since. »
Code HTTP 413 Request Entity Too Large
Le code d’état HTTP 413 « Request Entity Too Large » signifie que la requête HTTP que le client a envoyée au serveur est trop grande pour que le serveur puisse la traiter. Cela peut être dû à une URL trop longue ou à une entité de requête (comme un corps de POST ou PUT) qui est trop grande.
Voici quelques éléments à considérer lors de la réception ou de la gestion de ce code d’erreur :
Limitation de la taille de la requête : Le serveur a des limites de taille pour les requêtes afin de prévenir les attaques de déni de service (DoS) ou d’autres problèmes liés à la manipulation de très grandes quantités de données.
Corps de la requête : Si vous téléchargez un fichier ou envoyez des données via une requête POST ou PUT, vous pourriez recevoir ce message d’erreur si la taille des données dépasse la limite autorisée par le serveur.
Configuration du serveur : Les serveurs Web comme Apache ou Nginx permettent aux administrateurs de configurer les limites de taille des requêtes. Si vous êtes l’administrateur du serveur, vous pouvez augmenter cette limite dans la configuration du serveur, mais faites attention à ne pas compromettre la sécurité ou la performance du serveur.
Résolution : Si vous êtes un développeur ou un utilisateur final, vous pourriez essayer de réduire la taille de la requête en envoyant moins de données à la fois, en divisant la requête en plusieurs requêtes plus petites, ou en compressant les données si possible.
Headers : Il est aussi possible que des headers de requête trop volumineux puissent causer cette erreur.
Pour résoudre cette erreur, vous pourriez avoir besoin de réduire la taille de votre requête, ou, si vous contrôlez le serveur, ajuster les paramètres de configuration du serveur pour permettre des requêtes plus grandes.
Code HTTP 414 Request-URI Too Long
Le code d’erreur HTTP 414 « Request-URI Too Long » signifie que l’URI (Uniform Resource Identifier) utilisée par le client pour accéder à une ressource est trop longue. Cela peut se produire si le client envoie une URL excessivement longue dans la ligne de requête HTTP.
Voici quelques détails supplémentaires :
Cause possible : Généralement, cela peut se produire lors de l’utilisation de méthodes GET avec beaucoup de paramètres ou lors de l’envoi de données via l’URL.
Limitation du Serveur : La limitation sur la longueur de l’URI peut varier selon les serveurs web. Ils ont des restrictions sur la longueur maximale de l’URI pour éviter les problèmes de déni de service (DoS) ou autres problèmes de sécurité.
Correction : Pour corriger cette erreur, vous pourriez avoir besoin de réduire la longueur de l’URI ou d’utiliser une méthode POST au lieu d’une méthode GET, si possible. La méthode POST n’a pas de limitation sur la taille des données transmises, car les données sont envoyées dans le corps de la requête, et non dans l’URI.
Outils de Développeurs Web : Les développeurs web peuvent utiliser des outils et des techniques pour minimiser la longueur de l’URI, comme en réduisant les paramètres non nécessaires ou en utilisant des raccourcisseurs d’URL dans certains cas.
Exemple de Réponse HTTP : Voici à quoi pourrait ressembler une réponse HTTP contenant ce code d’erreur :
HTTP/1.1 414 Request-URI Too Long
Server: Apache/2.4.41 (Ubuntu)
Content-Type: text/html; charset=iso-8859-1
J’espère que cela vous donne une idée de ce que le code d’erreur 414 signifie et comment il peut être résolu.
Code HTTP 415 Unsupported Media Type
Le code d’erreur HTTP 415 Unsupported Media Type est une réponse standard du protocole HTTP qui signifie que le serveur ne peut pas traiter la requête parce que le format du média de la requête est inconnu ou n’est pas supporté par le serveur.
Dans un contexte de programmation ou de développement web, vous pourriez rencontrer ce code d’erreur pour diverses raisons, notamment :
Envoi de données dans un format que le serveur ne peut pas interpréter (par exemple, envoi de JSON à un endpoint qui s’attend à recevoir des données XML).
Envoi d’un fichier avec un type de média MIME qui n’est pas pris en charge par le serveur.
Une configuration incorrecte du serveur qui limite les types de médias pris en charge.
Pour résoudre ce problème, vous devrez soit ajuster le format de votre requête pour qu’il corresponde à ce que le serveur est capable de traiter, soit ajuster la configuration du serveur pour qu’il puisse traiter le type de média que vous essayez d’envoyer. »
Code HTTP 416 Requested range unsatisfiable
Le code d’état HTTP 416, « Requested Range Not Satisfiable » (ou « Plage demandée insatisfaisable » en français), est renvoyé par un serveur web lorsqu’un client (comme un navigateur web) demande une portion d’une ressource (comme un fichier) qui ne peut pas être satisfaite. Cela se produit généralement lorsque la plage spécifiée dans l’en-tête Range de la requête HTTP est en dehors de la taille de la ressource cible.
Voici quelques points à considérer à propos de ce code d’état :
Requête de Plage : Les clients peuvent utiliser des en-têtes de plage pour demander seulement une partie d’une ressource. Cela est souvent utilisé pour reprendre des téléchargements interrompus ou pour lire des vidéos en streaming.
Plage Hors Limites : Le code 416 est renvoyé lorsque la plage spécifiée est hors des limites de la ressource. Par exemple, si une ressource fait 1000 octets de taille, une demande de plage pour les octets 1500-2000 sera hors limites.
Réponse du Serveur : En réponse à une telle demande, le serveur renvoie le code d’état 416, indiquant que la plage demandée ne peut pas être satisfaite.
En-tête Content-Range : Dans la réponse, le serveur inclut également un en-tête Content-Range pour indiquer la taille totale de la ressource, afin que le client puisse ajuster sa demande de plage en conséquence.
Correction de la Requête : Le client peut corriger la requête en spécifiant une plage valide et en la renvoyant, ou en demandant la ressource entière sans utiliser un en-tête de plage.
Voici un exemple de ce à quoi pourrait ressembler une telle réponse :
HTTP/1.1 416 Requested Range Not Satisfiable
Date: Sun, 10 Sep 2023 12:34:56 GMT
Server: Apache
Content-Range: bytes */1000
Content-Length: 0
Content-Type: text/html
Dans cet exemple, l’en-tête Content-Range indique que la taille totale de la ressource est de 1000 octets (* indique que la plage demandée n’est pas satisfaisable).
Code HTTP 417 Expectation failed
Le code d’état HTTP 417 « Expectation Failed » est une réponse standard du serveur HTTP indiquant que le serveur ne peut pas répondre à l’exigence spécifiée dans les en-têtes de la demande.
Voici quelques détails supplémentaires à propos de ce code d’état :
- Définition : Ce code est retourné lorsque le serveur ne peut pas satisfaire une exigence mentionnée dans les en-têtes d’attente de la requête HTTP.
- Utilisation : Il est généralement utilisé dans le cadre de fonctionnalités avancées du protocole HTTP où le client spécifie des « attentes » que le serveur doit respecter. Ces « attentes » sont spécifiées dans l’en-tête « Expect » de la requête.
- En-Tête « Expect » : L’en-tête « Expect » est utilisé par le client pour spécifier certaines conditions que la requête doit respecter. Un exemple courant est « Expect: 100-continue », où le client demande au serveur de confirmer qu’il est prêt à recevoir le corps de la requête. Si le serveur ne peut pas satisfaire cette exigence, il renverra un code d’état 417.
- Résolution : La résolution de cette erreur peut impliquer soit la modification des en-têtes d’attente, soit la mise à jour du serveur pour qu’il puisse gérer l’exigence spécifiée.
- Documentation : Vous pouvez trouver des informations supplémentaires sur ce code d’état dans la spécification du protocole HTTP, plus précisément dans la RFC 2616, qui est disponible en ligne.
J’espère que cela vous donne une idée plus claire de ce qu’est le code d’état HTTP 417 « Expectation Failed ».
Code HTTP 418 I’m a teapot
Le code HTTP 418 « I’m a teapot » est une blague issue du protocole de contrôle de transmission et du protocole Internet (TCP/IP). Ce code a été introduit dans le cadre d’un poisson d’avril de l’Internet Engineering Task Force (IETF) en 1998, dans une publication appelée RFC 2324, aussi connu comme le protocole HTCPCP (Hyper Text Coffee Pot Control Protocol).
Dans la spécification originale, il est indiqué que le code 418 devrait être retourné par une théière lorsque quelqu’un tente de lui demander de préparer du café (ce qui est, évidemment, en dehors de ses capacités en tant que théière).
Voici une citation de la RFC 2324 décrivant l’erreur 418 :
2.3.2 418 I’m a teapot : Any attempt to brew coffee with a teapot should result in the error code « 418 I’m a teapot ». The resulting entity body MAY be short and stout.
C’est donc une plaisanterie qui a été largement adoptée et reconnue par la communauté des développeurs comme une blague légère au sein des codes d’état HTTP. Dans la pratique, ce code d’état n’est pas utilisé par les serveurs web réels, sauf peut-être à des fins humoristiques ou pour des easter eggs.
Code HTTP 419 Page expired
Le code d’état HTTP 419 « Page Expired » est souvent utilisé dans le contexte des applications web basées sur Laravel, un framework PHP, pour indiquer que la page demandée a expiré en raison du temps écoulé. C’est souvent une réponse à une demande qui nécessite une certaine forme de validation CSRF (Cross-Site Request Forgery) dont le token a expiré.
Un token CSRF est une forme de clé secrète qui est utilisée pour valider que les demandes faites à un site web proviennent bien d’un utilisateur légitime et non d’une attaque de type « man-in-the-middle » ou d’une autre source potentiellement malveillante.
Si le token CSRF expire (ce qui arrive après un certain laps de temps pour des raisons de sécurité), la demande sera rejetée et le serveur peut renvoyer un code 419 pour indiquer que la page (ou plutôt la demande) a « expiré ».
Comment résoudre l’erreur 419
- Les utilisateurs peuvent généralement simplement rafraîchir la page pour obtenir un nouveau token CSRF et ensuite réessayer leur demande.
- Les développeurs peuvent aussi ajuster la durée de vie des tokens CSRF dans les paramètres de configuration de leur application pour éviter que cette erreur ne se produise trop fréquemment. »
Code HTTP 421 Bad mapping / Misdirected Request
Le code HTTP 421 « Misdirected Request » est un statut qui signifie que la requête qui a été envoyée vers le serveur ne peut pas être servie par ce dernier, et qu’une autre instance ou connexion doit être utilisée à la place. Cette réponse peut être envoyée quand le serveur sait qu’il ne peut pas fournir une réponse cohérente, souvent en lien avec des configurations de protocoles de connexions ou de certificats TLS/SSL.
Voici quelques scénarios qui pourraient générer un code d’erreur 421 :
- Mauvaise configuration SSL/TLS : Le serveur est configuré pour servir un certain site, mais la requête correspond à un autre site hébergé sur le même serveur, et les configurations SSL/TLS ne correspondent pas.
- Problèmes de connexion HTTP/2 : Parfois, dans le cas de connexions HTTP/2, des erreurs de ce genre peuvent survenir si une seule connexion TCP est utilisée pour héberger plusieurs hôtes virtuels et que l’un d’eux n’est pas correctement configuré.
- Problèmes de routage de réseau : Le réseau peut mal acheminer la requête, la dirigeant vers un serveur qui n’est pas capable de gérer la requête correctement.
Comment corriger une erreur 421 ?
Il faudra probablement examiner et ajuster les configurations du serveur pour s’assurer que les requêtes sont correctement routées et que les configurations SSL/TLS sont correctes. »
Code HTTP 422 Unprocessable entity
Le code HTTP 422 ou « Unprocessable Entity », est un code de statut qui signifie que le serveur a compris la nature de la requête, mais qu’il ne peut pas la traiter en raison d’une erreur sémantique. En d’autres termes, la requête était bien formulée mais il y avait quelque chose dans la demande qui empêchait le serveur de pouvoir la compléter.
Voici quelques situations dans lesquelles ce code d’erreur peut être renvoyé :
- Un des champs requis dans la requête est manquant.
- Un des champs de la requête a une valeur qui n’est pas dans le format attendu ou qui est incompatible avec les autres valeurs fournies.
- Les données envoyées dans la requête violent les contraintes de validation du serveur.
Comment résoudre une erreur 422 ?
Le client doit examiner la réponse du serveur, qui devrait inclure des informations sur la nature de l’erreur, puis modifier la requête en conséquence avant de la renvoyer.
Code HTTP 423 Locked
Un code HTTP 423 « Locked » est une réponse d’état standard du protocole HTTP qui indique qu’une ressource à laquelle on essaie d’accéder est verrouillée et ne peut pas être modifiée pour le moment.
Ce verrouillage est généralement mis en place pour éviter des modifications concurrentes qui pourraient conduire à des états inconsistants ou corrompus pour la ressource.
Quand est-il utilisé le code 423 ?
Il est principalement utilisé dans des environnements où plusieurs clients peuvent tenter de modifier une même ressource simultanément. Ce verrouillage est une manière de contrôler et de sérialiser les accès pour éviter des situations de concurrence. Dans les systèmes qui implémentent le WebDAV (extensions de HTTP), ce code d’erreur est couramment utilisé.
Comment réagir au code 423 ?
Lorsqu’un client reçoit une réponse 423, il devrait réessayer la requête après un certain temps ou après que le verrouillage ait été levé.
Exemple : Supposons qu’un utilisateur tente de modifier un document qui est actuellement en cours de modification par un autre utilisateur. Dans ce cas, le serveur peut renvoyer un code d’état 423 pour indiquer que la ressource est temporairement verrouillée jusqu’à ce que l’autre utilisateur ait terminé ses modifications. »
Code HTTP 424 Failed Dependency
Le code d’état HTTP 424, qui est intitulé « Failed Dependency ». Ce code est défini dans l’extension WebDAV (RFC 4918) et indique qu’une opération a échoué en raison de l’échec d’une autre opération sur laquelle elle dépend.
Voici un exemple d’utilisation du code d’état 424:
Supposons qu’une requête WebDAV tente de modifier plusieurs ressources sur un serveur, mais qu’une des opérations échoue pour une raison quelconque. Dans ce cas, le serveur peut retourner un code d’état 424 pour indiquer que les opérations restantes ont échoué en raison de l’échec de la première opération.
Code HTTP 425 Too Early
Le code d’état HTTP 425 « Too Early » est une réponse standard du serveur HTTP qui indique que le client (en général, un navigateur web) a initié une requête trop tôt. Ce statut a été introduit dans le RFC 8470.
Ce code d’état est principalement utilisé avec les mécanismes qui permettent de protéger les échanges de données contre des attaques par répétition de requête (par exemple, dans le cadre du protocole TLS). Le code 425 indique qu’une requête a été refusée car elle nécessite une nouvelle « pre-handshake » (pré-poignée de main, ou accord préliminaire) pour garantir la sécurité de la communication.
En termes plus techniques, ce code est souvent utilisé dans des contextes où des en-têtes comme « Early-Data » sont impliqués, qui sont généralement manipulés pendant les étapes initiales de la négociation de sécurité.
Pour comprendre entièrement le contexte et l’utilisation de ce code d’état, il serait utile de se familiariser avec les concepts plus avancés de la sécurité web et de la transmission sécurisée des données.
Code HTTP 426 Upgrade Required
Le code d’état HTTP 426 « Upgrade Required » indique que le serveur refuse d’exécuter la requête en utilisant le protocole courant et que le client doit passer à un protocole différent pour que la requête puisse être traitée. Ce code est envoyé en réponse à une mise à niveau requise pendant la négociation du protocole.
Voici un exemple simple pour illustrer cela :
- Un client envoie une requête HTTP/1.1 à un serveur qui nécessite HTTP/2.0.
- Le serveur renvoie une réponse avec le code d’état 426, indiquant que la mise à niveau vers HTTP/2.0 est requise.
- Le message de réponse pourrait également inclure des informations sur la façon de procéder à la mise à niveau.
Dans la pratique, ce code est utilisé dans des situations où des mises à niveau de protocole sont nécessaires pour des raisons de sécurité ou de fonctionnalité améliorée.
Comment Le problème généré par le code HTTP 426 ?
Pour résoudre ce problème, le client doit être mis à jour ou configuré pour utiliser le protocole requis par le serveur.
Code HTTP 427 Invalid digital signature
Le code d’erreur HTTP 427 « Invalid Digital Signature » n’est pas un code d’état standard dans les spécifications HTTP utilisées pour le Web. Les codes d’état HTTP standard sont définis par l’Internet Engineering Task Force (IETF) et documentés dans des RFC tels que le RFC 7231 pour HTTP/1.1.
Cela dit, certains systèmes ou applications peuvent implémenter leurs propres codes d’état HTTP pour des situations spécifiques qui ne sont pas couvertes par la norme. Le code 427 « Invalid Digital Signature » pourrait être un exemple de cela, utilisé par une application spécifique pour indiquer qu’une signature numérique fournie avec une requête HTTP n’est pas valide ou ne peut pas être vérifiée.
Code HTTP 428 Precondition Required
Le code d’état HTTP 428 « Precondition Required » fait partie des codes d’état d’extension pour HTTP, qui ont été définis dans la spécification des extensions de WebDav (RFC 6585). Ce code d’état est utilisé pour indiquer qu’une condition préalable, généralement définie par des en-têtes de conditions tels que If-Match, If-None-Match, If-Modified-Since, If-Unmodified-Since, etc., est nécessaire mais n’a pas été satisfaite dans la requête du client.
Pour donner un peu plus de contexte, les en-têtes de précondition HTTP permettent au client de transférer la requête HTTP uniquement si certaines conditions sont remplies.
Voici comment cela fonctionne avec quelques en-têtes différents :
- If-Match : La requête sera exécutée seulement si l’entité cible correspond à l’entité donnée (généralement en comparant les ETags).
- If-None-Match : La requête sera exécutée seulement si l’entité cible ne correspond pas à l’entité donnée.
- If-Modified-Since : La requête sera exécutée seulement si l’entité cible a été modifiée depuis la date spécifiée.
- If-Unmodified-Since : La requête sera exécutée seulement si l’entité cible n’a pas été modifiée depuis la date spécifiée.
L’utilisation de ces en-têtes permet d’éviter des problèmes tels que les mises à jour concurrentes ou les lectures inappropriées de données obsolètes. Si le serveur renvoie un code d’état 428, cela signifie que la requête du client doit inclure le bon en-tête de précondition pour être traitée.
Code HTTP 429 Too Many Requests
Le code d’état HTTP 429 « Too Many Requests » est une réponse standard du serveur indiquant que l’utilisateur a envoyé trop de requêtes dans un certain laps de temps. Les serveurs web utilisent cette réponse pour prévenir les abus ou les attaques de déni de service (DDoS), en limitant le nombre de requêtes qu’un utilisateur peut envoyer dans un temps donné.
En recevant une réponse HTTP 429, le client doit comprendre que la limite de taux de requêtes allouées a été atteinte et qu’il doit attendre un certain temps avant de renvoyer des requêtes. Cette « attente » est souvent spécifiée dans les en-têtes de réponse, notamment via l’en-tête « Retry-After », qui indique combien de temps le client doit attendre avant de refaire une tentative.
Pour éviter de recevoir ce code d’erreur, les clients peuvent implémenter une logique de « refroidissement » (cooling down) pour éviter de dépasser les limites de taux de requêtes du serveur. Cette logique pourrait inclure des mécanismes comme les backoffs exponentiels pour espacer les requêtes successives.
Code HTTP 431 Request Header Fields Too Large
Un code d’état HTTP 431, « Request Header Fields Too Large », est renvoyé par un serveur web lorsqu’il estime que la taille des en-têtes (header fields) de la requête HTTP que le client a envoyée est trop importante et ne peut pas être traitée par le serveur. En d’autres termes, les en-têtes de la requête dépassent la limite que le serveur est prêt à accepter.
Voici quelques points à considérer lors de l’analyse ou de la résolution de ce genre d’erreur :
- En-têtes volumineux : L’erreur se produit souvent lorsque trop de données sont envoyées dans les en-têtes de la requête. Cela peut être dû à un cookie trop gros, à des en-têtes personnalisés trop longs, etc.
- Configuration du serveur : Les serveurs web ont des configurations qui définissent la taille maximale des en-têtes qu’ils peuvent accepter. Cette limite peut être modifiée dans les paramètres du serveur.
Comment résoudre le problème associé au code d’état HTTP 431 ?
- Côté client : Réduire la taille des en-têtes en envoyant moins de données. Cela pourrait signifier réduire la taille des cookies ou d’autres en-têtes personnalisés.
- Côté serveur : Augmenter la limite de taille des en-têtes que le serveur est prêt à accepter, bien que cela puisse potentiellement avoir des implications en matière de sécurité et de performance.
- Navigateurs Web : Dans certains cas, il peut être nécessaire de vider les cookies ou le cache du navigateur, car un vieux cookie ou un en-tête corrompu peut également provoquer cette erreur.
- Utilisation de bibliothèques ou d’API : Si vous utilisez une bibliothèque ou une API pour faire des requêtes HTTP, vérifiez que vous n’ajoutez pas accidentellement des en-têtes trop volumineux.
Pour résoudre cette erreur, vous devrez identifier la source spécifique des en-têtes volumineux et soit réduire leur taille, soit ajuster la configuration du serveur pour accepter de plus grands en-têtes.
Code HTTP 449 Retry With
Le code HTTP 449 « Retry With » n’est pas un code standard officiellement reconnu par les spécifications HTTP officielles (RFC 7231), mais il a été utilisé dans certaines implémentations, notamment dans les versions précédentes de Microsoft Internet Information Services (IIS).
Ce code a été utilisé pour indiquer que la requête ne peut pas être effectuée actuellement et que le client devrait réessayer avec des informations supplémentaires ou modifiées. Le « Retry With » pourrait indiquer que certaines conditions doivent être remplies avant que la requête puisse être traitée avec succès.
Dans la pratique, il est souvent préférable d’utiliser les codes de statut HTTP standard et bien établis pour éviter toute confusion ou incompatibilité avec différents clients ou navigateurs.
Code HTTP 450 Blocked by Windows Parental Controls
Le code HTTP 450 Blocked by Windows Parental Controls est une réponse non-standard qui n’est pas officiellement reconnue par la spécification HTTP. Cependant, il a été utilisé dans le passé par Microsoft pour indiquer qu’une page Web a été bloquée par les contrôles parentaux de Windows.
Ce code pourrait indiquer que l’accès à la page Web spécifique a été restreint par les paramètres de contrôles parentaux configurés sur le système Windows en cours d’utilisation. Les contrôles parentaux de Windows permettent aux parents ou aux administrateurs système de restreindre l’accès à certaines catégories de contenu ou à des sites Web spécifiques pour protéger les utilisateurs mineurs.
Veuillez noter que cette utilisation du code 450 n’est pas standard et ne serait reconnue que par les logiciels et systèmes spécifiquement configurés pour interpréter ce code de cette manière.
Code HTTP 451 Unavailable For Legal Reasons
Le code HTTP 451 « Unavailable For Legal Reasons » est une réponse du serveur qui signifie que l’accès à la ressource demandée a été bloqué pour des raisons juridiques. Ce code d’état a été proposé en référence à la célèbre dystopie de Ray Bradbury, « Fahrenheit 451 », où les livres sont interdits et brûlés par le gouvernement.
Ce code d’état peut être utilisé lorsqu’une page web ou une ressource est rendue inaccessible en raison de restrictions juridiques, comme des lois sur les droits d’auteur, des jugements de tribunaux ou d’autres réglementations gouvernementales.
Lorsque vous rencontrez ce code d’état, cela peut signifier que le contenu a été retiré ou bloqué dans une certaine région géographique ou juridiction, soit par le propriétaire du site web, soit par une directive du gouvernement ou une décision de justice.
Code HTTP 456 Unrecoverable Error
Le code d’état HTTP 456 « Unrecoverable Error » n’est pas un code standard dans le protocole HTTP tel que défini par les spécifications officielles de l’IETF (Internet Engineering Task Force).
Le code d’état 456 « Unrecoverable Error » n’appartient à aucune de ces catégories officielles et n’est pas reconnu comme un code d’état standard. Comme avec d’autres codes d’état non standards (comme par exemple, le code HTTP 427), si un système ou une application utilise ce code d’état, cela serait spécifique à ce système ou cette application.
Code HTTP 444 No Response
Le code HTTP 444 No Response est un code de statut HTTP non standard utilisé par certains serveurs, notamment le serveur web Nginx, pour indiquer qu’aucune réponse ne sera renvoyée à l’agent utilisateur (par exemple, un navigateur web) et que la connexion sera fermée. Cela est souvent utilisé pour signifier qu’une requête a été reconnue comme malveillante ou non désirée et que le serveur a choisi de ne pas répondre du tout à cette requête.
Il est à noter que ce code n’est pas un standard officiel défini par le groupe de travail HTTP de l’IETF (Internet Engineering Task Force), mais il est spécifique à Nginx et peut ne pas être reconnu ou manipulé de la même manière par tous les serveurs ou agents utilisateurs. Dans la documentation de Nginx, il est souvent mentionné dans le contexte de la gestion de requêtes non souhaitées ou malveillantes.
Code HTTP 495 SSL Certificate Error
Il semble y avoir une petite confusion. À ma dernière mise à jour en septembre 2021, le code d’erreur HTTP 495 n’est pas un code d’erreur HTTP standardisé reconnu par l’IANA (Internet Assigned Numbers Authority) ou défini dans une spécification RFC standard pour HTTP.
Cependant, certains serveurs ou applications Web peuvent définir leurs propres codes d’erreur HTTP personnalisés pour des situations spécifiques. Dans ce cas, il semble que le « »495 SSL Certificate Error » » est probablement un code d’erreur personnalisé utilisé par une application ou un serveur spécifique pour indiquer un problème avec le certificat SSL d’une requête client.
En général, les erreurs relatives aux certificats SSL peuvent être causées par divers problèmes, tels que :
- Un certificat SSL expiré.
- Un certificat SSL qui n’a pas été émis par une autorité de certification de confiance.
- Une incompatibilité entre le certificat SSL et le protocole SSL/TLS utilisé.
- Un certificat SSL qui ne correspond pas au nom de domaine de l’hôte.
Pour plus de précisions, il serait judicieux de vérifier la documentation du serveur ou de l’application en question qui utilise ce code d’erreur personnalisé.
Code HTTP 496 SSL Certificate Required
Le code d’erreur HTTP 496 n’est pas un code d’erreur standard ou officiel dans le protocole HTTP. Les codes d’erreur HTTP standards sont définis par la spécification HTTP et sont enregistrés par l’Internet Assigned Numbers Authority (IANA).
Cependant, il est possible que certaines organisations ou logiciels créent leurs propres codes d’erreur HTTP pour des situations spécifiques. Dans ce cas, le « 496 SSL Certificate Required » pourrait être un code d’erreur personnalisé utilisé par une application ou un service spécifique pour indiquer qu’une requête nécessite une certification SSL pour procéder.
Voici quelques codes d’erreur HTTP standards qui sont liés aux certificats SSL :
- 495 SSL Certificate Error : Ce code d’erreur non standard est utilisé pour indiquer une erreur de certificat SSL.
- 496 SSL Certificate Required : Ce code d’erreur non standard peut être utilisé pour indiquer qu’un certificat SSL est requis pour accéder à une ressource.
- 497 HTTP Request Sent to HTTPS Port : Ce code d’erreur non standard est utilisé pour indiquer qu’une requête HTTP a été envoyée à un port qui attend des requêtes HTTPS.
Code HTTP 497 HTTP Request Sent to HTTPS Port
Le code d’erreur HTTP 497 est une réponse non-standard qui est parfois utilisée par certains serveurs web pour indiquer que le client a envoyé une requête HTTP à un port qui est configuré pour écouter les requêtes HTTPS (généralement port 443). Cela se produit généralement lorsque le client tente d’accéder à une ressource qui nécessite une connexion sécurisée (HTTPS) mais utilise un protocole non sécurisé (HTTP) pour envoyer la requête.
Pour résoudre cette erreur, le client doit s’assurer qu’il utilise le protocole HTTPS lorsqu’il envoie une requête à un port configuré pour écouter les requêtes HTTPS.
Voici quelques façons de le faire :
- Modification de l’URL : Changez « http » en « »https » dans l’URL. Par exemple, au lieu de « http://www.exemple.com », utilisez « https://www.exemple.com ».
- Redirection de serveur : Configurez le serveur pour rediriger automatiquement les requêtes HTTP vers HTTPS.
- Mise à jour de la configuration du serveur : Si vous contrôlez le serveur, vous pourriez avoir besoin de mettre à jour la configuration du serveur pour écouter correctement les requêtes HTTP et HTTPS sur les ports appropriés.
Il convient de noter que le code 497 n’est pas un code d’erreur standardisé et n’est pas universellement utilisé par tous les serveurs web.
Code HTTP 498 Token expired/invalid
Le code d’état HTTP 498 « Token expired/invalid » n’est pas inclus dans les standards officiels HTTP définis par l’IETF (Internet Engineering Task Force) dans des documents tels que le RFC 7231 pour HTTP/1.1.
Certains systèmes, applications ou frameworks peuvent définir leurs propres codes d’état HTTP pour gérer des situations spécifiques non couvertes par les standards officiels. Le code 498 « Token expired/invalid » est un exemple de cela.
Il est généralement utilisé pour indiquer que le jeton d’authentification (token) fourni avec la requête HTTP est expiré (Token expired) ou invalide (Token invalid). Ce mécanisme est souvent employé dans des contextes où la sécurité est critique, comme les API REST qui nécessitent une authentification basée sur des jetons pour accéder à des ressources protégées.
Code HTTP 499 Client Closed Request
Le code HTTP 499 « Client Closed Request » est un code de réponse HTTP qui n’est pas défini dans les spécifications HTTP standard, telles que définies dans les RFC (Request for Comments) de l’IETF (Internet Engineering Task Force). Cela signifie que ce code n’est pas officiellement reconnu comme faisant partie de la norme HTTP.
Cependant, le code HTTP 499 est parfois utilisé par certains serveurs web, en particulier le serveur web Nginx, pour indiquer qu’une requête a été interrompue par le client avant que le serveur n’ait pu envoyer une réponse complète. Cela se produit généralement lorsque le client (généralement un navigateur web) ferme la connexion avant que le serveur n’ait terminé de traiter la demande. Le serveur web Nginx a choisi d’utiliser le code 499 à des fins de journalisation et de suivi, bien que cela ne fasse pas partie de la spécification HTTP officielle.
Il est important de noter que la signification d’un code HTTP peut varier d’un serveur à l’autre, car les serveurs peuvent ajouter leurs propres codes de réponse personnalisés pour des besoins spécifiques. Par conséquent, si vous rencontrez un code HTTP 499 dans un contexte particulier, il est recommandé de consulter la documentation du serveur ou du framework web spécifique que vous utilisez pour comprendre sa signification précise.
){kind=link}