TOC

Comment faire pour résoudre les codes d’erreur HTTP courants

introduction

Lors de l’accès à un serveur Web ou à une application, un code d’état HTTP est répondu à chaque demande HTTP reçue par un serveur. Les codes d’état HTTP sont des codes à trois chiffres et sont regroupés en cinq classes différentes. La classe d’un code d’état peut être rapidement identifiée par son premier chiffre:

  • 1xx: informatif

  • 2xx: succès

  • 3xx: redirection

  • 4xx: erreur client

  • 5xx: Erreur du serveur

Ce guide se concentre sur l’identification et le dépannage des codes HTTP * error * les plus couramment rencontrés, c.-à-d. Codes d’état 4xx et 5xx, du point de vue de l’administrateur système. De nombreuses situations peuvent amener un serveur Web à répondre à une demande avec un code d’erreur particulier. Nous couvrirons les causes et solutions potentielles courantes.

Vue d’ensemble des erreurs client et serveur

Les erreurs client ou les codes d’état HTTP de 400 à 499 résultent de requêtes HTTP envoyées par un client utilisateur (c.-à-d. un navigateur Web ou un autre client HTTP). Bien que ces types d’erreur soient liés au client, il est souvent utile de connaître le code d’erreur qu’un utilisateur rencontre pour déterminer si le problème potentiel peut être résolu par la configuration du serveur.

Les erreurs de serveur, ou les codes d’état HTTP de 500 à 599, sont renvoyées par un serveur Web s’il est conscient du fait qu’une erreur s’est produite ou ne peut pas autrement traiter la demande.

Conseils généraux de dépannage

  • Lors de l’utilisation d’un navigateur Web pour tester un serveur Web, actualisez le navigateur après avoir apporté des modifications au serveur.

  • Consultez les journaux du serveur pour plus de détails sur la manière dont le serveur traite les demandes. Par exemple, les serveurs Web tels que Apache ou Nginx produisent deux fichiers appelés + access.log + et + error.log + qui peuvent être analysés pour rechercher des informations pertinentes.

  • N’oubliez pas que les définitions de code d’état HTTP font partie d’une norme implémentée par l’application qui traite les demandes. Cela signifie que le code d’état réel renvoyé dépend de la manière dont le logiciel serveur traite une erreur particulière. Ce guide doit généralement vous indiquer la bonne direction.

Maintenant que vous avez une compréhension de haut niveau des codes d’état HTTP, examinons les erreurs courantes.

[[400-bad-request]] === 400 mauvaise demande

Le code d’état 400, ou l’erreur Bad Request, signifie que la requête HTTP envoyée au serveur a une syntaxe non valide.

Voici quelques exemples de situations dans lesquelles une erreur 400 Bad Request peut survenir:

  • Le cookie de l’utilisateur associé au site est corrompu. Effacer le cache du navigateur et les cookies pourraient résoudre ce problème

  • Requête mal formée en raison d’un navigateur défectueux

  • Requête mal formée due à une erreur humaine lors de la création manuelle de requêtes HTTP (par exemple, en utilisant + curl + de manière incorrecte)

[[401-unauthorized]] === 401 non autorisé

Le code d’état 401 ou une erreur Unauthorized signifie que l’utilisateur qui tente d’accéder à la ressource n’a pas été authentifié ou n’a pas été authentifié correctement. Cela signifie que l’utilisateur doit fournir des informations d’identification pour pouvoir afficher la ressource protégée.

Un exemple de scénario dans lequel une erreur 401 non autorisée serait renvoyée serait si un utilisateur essayait d’accéder à une ressource protégée par une authentification HTTP, comme dans https://www.digitalocean.com/community/tutorials/how-to-set-up -http-authentication-with-nginx-on-ubuntu-12-10 [ce tutoriel sur Nginx]. Dans ce cas, l’utilisateur recevra un code de réponse 401 jusqu’à ce qu’il fournisse un nom d’utilisateur et un mot de passe valides (ceux qui existent dans le fichier + .htpasswd +) au serveur Web.

[[403-forbidden]] === 403 interdit

Le code d’état 403, ou une erreur Forbidden, signifie que l’utilisateur a effectué une demande valide mais que le serveur refuse de le servir, en raison d’un manque d’autorisation pour accéder à la ressource demandée. Si vous rencontrez une erreur 403 de manière inattendue, quelques causes typiques sont expliquées ici.

Autorisations de fichier

Les erreurs 403 se produisent généralement lorsque l’utilisateur qui exécute le processus du serveur Web ne dispose pas des autorisations suffisantes pour lire le fichier en cours d’accès.

Pour donner un exemple de dépannage d’une erreur 403, supposons la situation suivante:

  • L’utilisateur tente d’accéder au fichier d’index du serveur Web à partir de + http: // example.com / index.html +

  • Le processus de travail du serveur Web appartient à l’utilisateur + www-data

  • Sur le serveur, le fichier d’index se trouve dans + / usr / share / nginx / html / index.html

Si l’utilisateur reçoit une erreur 403 Forbidden, assurez-vous que l’utilisateur + www-data dispose des autorisations suffisantes pour lire le fichier. Cela signifie généralement que les autres autorisations du fichier doivent être définies sur read. Il y a plusieurs façons de s’en assurer, mais la commande suivante fonctionnera dans ce cas:

sudo chmod o=r /usr/share/nginx/html/index.html

.htaccess

Une autre cause potentielle d’erreurs 403, souvent intentionnelle, est l’utilisation d’un fichier + .htaccess. Le fichier + .htaccess + peut être utilisé pour refuser l’accès de certaines ressources à des adresses IP ou à des plages spécifiques, par exemple.

Si l’utilisateur obtient une erreur 403 Forbidden de manière inattendue, assurez-vous qu’elle n’est pas provoquée par vos paramètres + .htaccess +.

Le fichier d’index n’existe pas

Si l’utilisateur tente d’accéder à un répertoire ne disposant pas d’un fichier d’index par défaut et que les listes de répertoires ne sont pas activées, le serveur Web renvoie une erreur 403 Forbidden. Par exemple, si l’utilisateur tente d’accéder à + ​​http: // example.com / emptydir / +, et qu’aucun fichier d’index ne se trouve dans le répertoire + emptydir + sur le serveur, un statut 403 sera renvoyé.

Si vous souhaitez que les listes de répertoires soient activées, vous pouvez le faire dans la configuration de votre serveur Web.

[[404-not-found]] === 404 introuvable

Le code d’état 404, ou une erreur Not Found, signifie que l’utilisateur peut communiquer avec le serveur mais ne peut pas localiser le fichier ou la ressource demandé.

Des erreurs 404 peuvent survenir dans une grande variété de situations. Si l’utilisateur reçoit une erreur 404 Not Found de manière inattendue, voici quelques questions à poser lors du dépannage:

  • Le lien qui a dirigé l’utilisateur vers votre ressource serveur contient-il une erreur typographique?

  • L’utilisateur a-t-il saisi une mauvaise URL?

  • Le fichier existe-t-il au bon endroit sur le serveur? La ressource a-t-elle été déplacée ou supprimée sur le serveur?

  • La configuration du serveur a-t-elle le bon emplacement racine du document?

  • L’utilisateur propriétaire du processus de travail du serveur Web dispose-t-il de privilèges pour accéder au répertoire dans lequel se trouve le fichier demandé? (Indice: l’accès aux répertoires nécessite des autorisations de lecture et d’exécution)

  • L’accès à la ressource est-il un lien symbolique? Si tel est le cas, assurez-vous que le serveur Web est configuré pour suivre les liens symboliques.

[[500-internal-server-error]] === 500 Erreur de serveur interne

Le code d’état 500, ou Internal Server Error, signifie que le serveur ne peut pas traiter la demande pour une raison inconnue. Parfois, ce code apparaîtra lorsque des erreurs plus spécifiques 5xx seront plus appropriées.

La cause la plus courante de cette erreur est une mauvaise configuration du serveur (par exemple, un fichier + .htaccess + malformé) ou des packages manquants (par exemple: essayer d’exécuter un fichier PHP sans que PHP soit installé correctement).

[[502-bad-gateway]] === 502 Mauvaise passerelle

Le code d’état 502, ou l’erreur Bad Gateway, signifie que le serveur est une passerelle ou un serveur proxy et qu’il ne reçoit pas de réponse valide des serveurs principaux qui devraient en réalité répondre à la demande.

Si le serveur en question est un serveur proxy inverse, tel qu’un équilibreur de charge, voici quelques points à vérifier:

  • Les serveurs principaux (où les demandes HTTP sont transférées) sont en bon état

  • Le proxy inverse est configuré correctement, avec les backends appropriés spécifiés

  • La connexion réseau entre les serveurs principaux et le serveur proxy inverse est saine. Si les serveurs peuvent communiquer sur d’autres ports, assurez-vous que le pare-feu autorise le trafic entre eux.

  • Si votre application Web est configurée pour écouter sur un socket, assurez-vous que le socket existe au bon emplacement et qu’il dispose des autorisations appropriées.

[[503-service-unavailable]] === 503 Service Indisponible

Le code d’état 503 ou l’erreur Service Unavailable signifie que le serveur est surchargé ou en cours de maintenance. Cette erreur implique que le service deviendra disponible à un moment donné.

Si le serveur n’est pas en maintenance, cela peut indiquer que le serveur ne dispose pas de suffisamment de ressources de processeur ou de mémoire pour traiter toutes les demandes entrantes, ou que le serveur Web doit être configuré pour autoriser davantage d’utilisateurs, de threads ou de processus.

[[504-gateway-timeout]] === 504 portail expiré

Le code d’état 504 ou l’erreur Gateway Timeout signifie que le serveur est une passerelle ou un serveur proxy et qu’il ne reçoit pas de réponse des serveurs dorsaux dans le délai imparti.

Cela se produit généralement dans les situations suivantes:

  • La connexion réseau entre les serveurs est mauvaise

  • Le serveur principal qui répond à la demande est trop lent, en raison de performances médiocres.

  • Le délai d’expiration de la passerelle ou du serveur proxy est trop court

Conclusion

Maintenant que vous connaissez les codes d’erreur HTTP les plus courants et les solutions courantes à ces codes, vous devez disposer d’une base solide pour résoudre les problèmes liés à vos serveurs Web ou à vos applications.

Si vous rencontrez des codes d’erreur qui n’ont pas été mentionnés dans ce guide, ou si vous connaissez d’autres solutions probables à celles décrites, n’hésitez pas à en discuter dans les commentaires!

Related