Dans le monde du développement web, les codes d'erreur HTTP jouent un rôle essentiel dans l'expérience utilisateur et la réputation d'un site web. Dans cet article, nous examinerons une liste complète des codes d'erreur serveur, analyserons leur signification et apprendrons à interpréter efficacement les codes de réponse serveur afin de résoudre les problèmes et d'optimiser les performances des applications web.
Qu'est-ce qu'un code de réponse HTTP
Le code de réponse HTTP est le langage des serveurs web qui traduit les requêtes du navigateur en instructions compréhensibles. Il est comparable à un poète répondant à des questions virtuelles, leur donnant sens et orientation. Les codes de réponse ne sont pas toujours des codes d'erreur HTTP. Par exemple, « 200 OK » signifie que tout est OK, tandis que l'erreur HTTP « 404 Not Found » indique que la page est perdue dans l'espace virtuel. Chaque code est une expression unique de l'état du serveur, dont le décodage nous permet de comprendre ce qui se passe de l'autre côté du monde virtuel.
Codes 1xx (Informations)
Les codes d'état 1xx du protocole HTTP constituent en quelque sorte le premier maillon du dialogue entre le serveur et le client. Au lieu de fournir une réponse complète à une requête, ils fournissent des informations sur l'état actuel, améliorant ainsi l'efficacité des échanges de données. Examinons-les de plus près :
100 Continuer . Code de réponse HTTP dans lequel le serveur autorise l'utilisateur à poursuivre l'envoi d'une requête volumineuse en toute sécurité.
101 Changement de protocole . Le serveur informe le client qu'il modifie les règles de communication, par exemple en passant de HTTP à HTTPS, plus sécurisé. Dans ce cas, l'en-tête « Upgrade » est utilisé pour signaler ce changement de protocole.
102 Traitement . Ce code est comme un message indiquant que le serveur a accepté la requête, mais qu'il est encore occupé par une opération complexe.
103 Premiers indices . Ici, le serveur envoie plusieurs en-têtes indicatifs au client avant la réponse principale, l'avertissant d'un élément qui pourrait être pertinent dans un avenir proche.
Code 2xx (réussi)
Les codes d'erreur HTTP du groupe 2xx indiquent une requête réussie du serveur. Ils agissent comme un « feu vert » dans le cadre des communications web, confirmant que tout se déroule comme prévu et que l'opération a été menée à bien.
200 OK . Ce statut est utilisé lorsque le serveur traite une requête GET sans problème et renvoie les données demandées. L'en-tête « Content-Type » indique le type de contenu de la réponse. Il informe simplement le client que la requête a abouti.
201 Créé . Ici, le serveur annonce la création d'une nouvelle ressource.
202 Accepté . Le serveur informe l'utilisateur que la requête a été acceptée, mais qu'il lui faudra un certain temps pour répondre.
203 Informations non officielles . Ce code fournit au client des données qui peuvent ne pas être officielles, mais qui peuvent être utilisées à des fins de comparaison.
204 Aucun contenu . Le serveur a traité la requête mais ne renvoie aucun contenu supplémentaire.
205 Réinitialiser le contenu . Ici, le client est invité à réinitialiser la vue ou les données actuelles après l'envoi.
206 Contenu partiel . Ce cas indique que la réponse ne contient qu'une partie du contenu demandé. L'en-tête « Content-Range » précise la plage de contenu partielle.
207 Multi-Statut. Le serveur a traité avec succès une requête multi-opérations du client et la réponse contient des informations sur l'état de chacune des opérations.
226 IM utilisé . Ce code indique que le serveur a utilisé la méthode Incremental Metadata (IM) et a répondu en ne transmettant au client que les parties de ressources modifiées.
Codes 3xx (Redirections)
Les codes 3xx du protocole HTTP sont comme des pointeurs qui guident l'utilisateur vers une nouvelle ressource. Ils informent le client des étapes à suivre pour obtenir le contenu demandé ou être redirigé vers une autre ressource. Examinons chacun d'eux en détail :
300 Choix multiples . Le client reçoit un signal indiquant que la ressource peut se trouver à plusieurs emplacements et doit faire un choix. Dans le cas présent, l'en-tête « Emplacement » peut indiquer d'autres options pour la ressource.
301 Déplacement définitif. Le serveur signale à l'utilisateur que la ressource a été déplacée définitivement vers un autre emplacement.
302 Found . Ce code HTTP correspond à une redirection temporaire. Le serveur informe le client que la ressource est temporairement disponible à une autre URL. L'en-tête « Location » pointe vers cette nouvelle URL.
303 Voir Autre . Le client est informé que la ressource est disponible à une URL différente et doit effectuer une requête GET à cette nouvelle adresse.
304 Non modifié . Ce statut indique au client que la ressource est restée inchangée depuis la dernière requête et qu'il n'est pas nécessaire de la télécharger à nouveau. Lors d'une requête, l'en-tête « If-Modified-Since » est utilisé pour vérifier si la ressource a été modifiée.
305 Utiliser un proxy. En guise de réponse, le serveur indique qu'il doit utiliser le proxy spécifié pour accéder à la ressource demandée.
306 (réservé) — Le code a été réservé, mais en réalité il n'est pas utilisé.
Redirection temporaire 307. Ce code est similaire à 302 Found, mais exige que le client reste dans la méthode de requête utilisée dans la requête d'origine.
Redirection permanente 308. Indique que la ressource a été déplacée définitivement vers une nouvelle URI et que le client doit utiliser cette nouvelle URI pour toutes les requêtes futures.
Erreur HTTP 4xx (erreurs client)
Les codes d'erreur HTTP 4xx indiquent des erreurs client. Cela signifie que le problème se situe du côté de l'utilisateur, par exemple au niveau du navigateur web ou de l'application.
400 Mauvaise requête . Le serveur ne peut pas traiter la requête en raison d'erreurs de syntaxe, de données invalides ou d'autres erreurs côté client.
401 Non autorisé. Le serveur ne peut pas traiter la requête en raison d'erreurs de syntaxe, de données invalides ou d'autres erreurs côté client.
402 Paiement requis . Ce code est actuellement inactif et réservé pour un usage ultérieur. Il pourrait indiquer la nécessité d'un paiement pour accéder à la ressource.
Erreur HTTP 403 : Accès interdit. Le client ne dispose pas des droits suffisants pour accéder à la ressource demandée.
404 Non trouvé. La ressource demandée n'existe pas sur le serveur. Il s'agit d'une des erreurs utilisateur les plus fréquentes.
405 Méthode non autorisée . Le serveur ne prend pas en charge la méthode de requête spécifiée pour cette ressource. L'en-tête « Allow » indique les méthodes autorisées pour cette ressource. Avec ce code,
406 Non acceptable. Le serveur ne peut pas fournir de données dans un format compatible avec le client.
407 Authentification proxy requise . L'authentification auprès du serveur proxy est requise pour accéder à la ressource demandée.
408 Délai d'attente dépassé . Le serveur attendait une requête du client, mais le délai a expiré. L'en-tête « Retry-After » peut indiquer le délai après lequel la requête peut être réessayée.
409 Conflit. La requête ne peut être traitée en raison d'un conflit avec l'état actuel de la ressource.
410 Ressource supprimée . La ressource demandée existait auparavant, mais elle a été supprimée et sa restauration n'est pas prévue.
411 Longueur requise . Le serveur exige que la longueur du contenu soit spécifiée dans la requête ; l’absence de cette information est considérée comme une erreur.
412 Précondition non remplie . Une précondition de la requête n'est pas satisfaite, ce qui empêche son exécution.
413 Charge utile trop volumineuse . La taille des données de la requête dépasse les limites du serveur.
414 URI trop longue . La longueur de l'URI dans la requête dépasse les limites acceptables.
415 Type de média non pris en charge . Le serveur ne peut pas traiter le type de données fourni dans la requête.
416 Plage non satisfaisante . Erreur HTTP : la plage demandée ne correspond pas aux données actuelles du serveur.
417 Échec de l'attente . La condition attendue dans l'en-tête « Expect » n'a pas été remplie.
418 Je suis une théière . Ce code est une plaisanterie et n'implique aucune action réelle de la part de l'utilisateur ou du serveur. Il ne s'agit pas d'une erreur à proprement parler. Il indique simplement que le serveur est une théière et qu'il est incapable de faire du café.
421 Requête mal adressée . Le serveur ne traite pas la requête en raison d'une erreur dans la requête ou la configuration du serveur.
422 Entité non traitable . Le serveur comprend la requête, mais ne la traite pas en raison d'erreurs de données.
423 Verrouillé. La ressource est bloquée et ne peut pas être traitée.
424 Dépendance non satisfaite . La requête dépend d'une autre requête non exécutée.
425 Trop tôt. Le serveur n'est pas prêt à traiter la requête car elle est arrivée trop tôt.
426 Mise à niveau requise . Le serveur nécessite l'utilisation d'un protocole plus avancé pour traiter la requête.
428 Précondition requise . Le serveur exige que certaines conditions préalables soient spécifiées dans la requête.
429 Trop de requêtes . Le client a envoyé trop de requêtes en peu de temps, dépassant les limites du serveur.
431 Champs d'en-tête de requête trop volumineux . Les en-têtes de requête dépassent la taille maximale autorisée.
449 Réessayer avec. Indique que la requête ne peut pas être exécutée par le serveur actuel, mais peut être traitée avec succès par un autre serveur, et que le client doit réessayer la requête avec un nouvel URI.
451 Indisponible pour des raisons juridiques . La ressource est indisponible pour des raisons juridiques.
499 Requête fermée par le client . Le serveur a reçu la requête, mais la connexion a été fermée par le client avant la fin du traitement.
Erreur HTTP 5xx (erreurs de serveur)
Les codes d'erreur HTTP 5xx indiquent des problèmes de serveur. Ces codes indiquent des problèmes survenus côté serveur, empêchant le serveur de traiter correctement la requête de l'utilisateur. Examinons-les de plus près :
Erreur HTTP 500 : Erreur interne du serveur . Le serveur rencontre des circonstances inattendues qui l'empêchent de terminer la requête. L'en-tête « Server » peut indiquer le serveur sur lequel l'erreur s'est produite.
Erreur 501 : Non implémenté . Le serveur ne prend pas en charge la fonctionnalité requise pour traiter la requête du client. L’en-tête « Via » peut indiquer le serveur proxy par lequel l’erreur s’est produite.
Erreur 502 Bad Gateway . Ce code signifie que le serveur faisant office de proxy a reçu une réponse incorrecte d'un autre serveur.
Erreur HTTP 503 : Service indisponible . Le serveur est temporairement incapable de traiter les requêtes.
Erreur 504 : Délai d’attente de la passerelle dépassé . Le serveur faisant office de proxy n’a pas reçu de réponse dans un délai raisonnable de la part d’un autre serveur.
Erreur 505 : Version HTTP non prise en charge . Le serveur ne prend pas en charge la version du protocole HTTP spécifiée dans la requête. À titre de solution de repli, l’en-tête « Upgrade » peut indiquer les protocoles pris en charge.
506 Variant Also Negotiates . Ce statut n'est pas utilisé dans HTTP/1.1 ; cependant, si le serveur détecte une configuration interne entraînant une ambiguïté dans la négociation du contenu, il peut utiliser cette réponse.
507 Espace de stockage insuffisant . Le serveur ne peut pas traiter la requête en raison d'un espace de stockage insuffisant.
508 Boucle détectée . Le serveur a détecté une boucle lors du traitement de la requête et refuse de la terminer afin d'éviter une boucle infinie.
509 Limite de bande passante dépassée . Cette erreur se produit lorsque la bande passante du serveur est dépassée en raison d'un volume élevé de requêtes ou de trafic.
510 Non prolongé . Le client doit demander des prolongations supplémentaires pour que la demande puisse se poursuivre.
511 Authentification réseau requise . Le client doit s'authentifier pour accéder au réseau.
Comment vérifier le code d'état de la page
Dans cette section, nous examinerons trois principales méthodes pour vérifier le code d'état d'une page : via la ligne de commande, via un navigateur web et via des services en ligne indépendants. Chacune de ces méthodes présente ses propres avantages et peut s'avérer utile dans différentes situations.
Vérification de la réponse du serveur via la ligne de commande
La ligne de commande permet de consulter facilement le code d'état d'une page sans utiliser de navigateur web. Pour cela, ouvrez la ligne de commande et exécutez la commande suivante :
curl -I http://page-addressCette commande envoie une requête HEAD (requête d'en-têtes uniquement) à l'URL spécifiée et affiche des informations, notamment le code d'état HTTP :
L'exemple ci-dessus montre un code de réponse réussi. Si la réponse contient un code d'erreur, comme « 404 Not Found », le résultat sera similaire :
Vérification de la réponse du serveur via la console du navigateur
La console de développement du navigateur web propose des outils permettant d'effectuer diverses opérations, notamment la vérification du code d'état de la page. Pour afficher le code HTTP dans la réponse du serveur, ouvrez la console de développement (Ctrl+Maj+K) ou (Ctrl+Maj+J) selon le navigateur utilisé. Sélectionnez ensuite la section « Réseau » et chargez la page souhaitée :
Vérification de la réponse du serveur à l'aide d'outils indépendants
De nombreux services en ligne indépendants proposent des outils pour vérifier le code d'état d'une page web. Ces services permettent généralement d'obtenir rapidement un aperçu de la disponibilité et des performances de votre ressource. Ils fonctionnent tous selon le même principe. Prenons comme exemple le service le plus populaire : httpstatus.io
Tout d'abord, vous devez ouvrir le service lui-même, puis entrer l'adresse de la page dont vous avez besoin pour trouver la réponse et demander une vérification :
Le résultat sera affiché en bas de la page :
Conclusion
En conclusion, il convient de souligner que la compréhension et la capacité à lire les codes d'erreur HTTP sont essentielles pour toute personne impliquée dans le développement web et la maintenance de serveurs. En identifiant chaque erreur et en explorant les outils permettant de les détecter, nous comprenons l'importance d'une gestion efficace de ces aspects des services web.
