Dépannage des codes d'erreur HTTP courants

Tout serveur web recevant une requête HTTP reçoit en réponse un code de statut HTTP. Ces codes sont de brèves notes du serveur décrivant la situation. Ils ne contiennent aucun contenu réel du site. Au lieu de cela, il s'agit d'un rapport sur la façon dont les choses se sont déroulées après la réception de la requête HTTP. Dans de nombreuses situations, ces codes sont importants pour diagnostiquer divers problèmes de serveur/client.

Ces codes sont des entiers de trois chiffres, chacun signifiant différents statuts. En fonction du premier chiffre, les codes HTTP sont divisés en cinq catégories :

• Réponses d'information : La valeur va de 100 à 199. Elle indique que la requête a été reçue et est en cours de traitement.

• Réponses de réussite : La valeur va de 200 à 299. Elle indique que l'action a été reçue, comprise et acceptée avec succès.

• Messages de redirection : La valeur va de 300 à 399. Elle signifie que des actions supplémentaires sont nécessaires pour compléter la requête.

• Réponses d'erreur du client : La valeur va de 400 à 499. Soit la requête contient des syntaxes incorrectes, soit elle ne peut pas être satisfaite.

• Réponses d'erreur du serveur : La valeur va de 500 à 599. Elle signifie que le serveur n'a pas réussi à traiter une requête valide.

Dans ce guide, nous aborderons certains des codes d'erreur HTTP les plus courants que tout le monde rencontre (4xx et 5xx), du point de vue d'un administrateur système. De nombreuses situations peuvent amener le serveur web à répondre avec un code particulier. De plus, ce tutoriel abordera les causes et solutions potentielles.

Erreurs client vs serveur

Les codes d'erreur 400 à 499 proviennent du client de l'utilisateur (un navigateur web ou tout client HTTP). Bien que les erreurs soient principalement liées au client, il est utile de savoir quel code un utilisateur rencontre. Cela peut aider à déterminer si un problème potentiel se situe du côté serveur.

Les erreurs de serveur (codes de statut HTTP 500 à 599), quant à elles, surviennent lorsque le serveur est conscient qu'une erreur s'est produite ou n'est pas en mesure de traiter la requête.

Dépannage général

Indépendamment de l'erreur, voici quelques conseils généraux de dépannage que vous devriez tester en premier lorsque vous êtes confronté à un code d'erreur HTTP :

• Lors de l'utilisation d'un navigateur web pour tester le serveur, il est recommandé de rafraîchir le navigateur après avoir apporté des modifications au serveur.

• Le journal du serveur contient des informations détaillées sur la façon dont le serveur traite les requêtes. Par exemple, les serveurs web populaires comme Apache et Nginx produisent des fichiers access.log et error.log. La vérification de ces journaux peut révéler des informations utiles.

• Les codes d'erreur HTTP font partie d'une norme. Les programmes implémentent cette norme en fonction de la manière dont ils gèrent les requêtes. Cela signifie qu'un code de statut particulier est renvoyé selon la façon dont le logiciel serveur gère l'erreur en question.

Ce guide devrait servir de ligne directrice utile pour identifier la source du problème.

Erreurs HTTP courantes

1. Erreurs client courantes

Le code d'erreur 400 indique une mauvaise requête (Bad Request). Il indique que la requête HTTP envoyée au serveur contient une syntaxe invalide. Jetons un coup d’œil aux sources potentielles de ces syntaxes incorrectes :

• Les cookies liés au site peuvent être corrompus. Nettoyer les cookies et le cache du navigateur peut résoudre le problème.

• Le navigateur web qui envoie la requête peut être défectueux ou comporter des bogues.

• Il peut s'agir d'une mauvaise requête due à une erreur lors de la formulation manuelle des requêtes HTTP, par exemple, une utilisation incorrecte de curl.

Le code d'erreur 401 (Non autorisé) se produit lorsque la requête tente d'accéder à des ressources qui n'ont pas été authentifiées ou qui ne l'ont pas été correctement. Pour résoudre le problème, l'utilisateur doit fournir les identifiants nécessaires pour accéder à la ressource protégée.

Un exemple de situation serait lorsque l'utilisateur tente d'accéder à une ressource protégée par une authentification HTTP. Dans une telle situation, l'utilisateur recevra un code d'erreur 401 à moins qu'un nom d'utilisateur et un mot de passe valides ne soient fournis.

Le code d'erreur 403 (Interdit) fait référence à une situation où la requête de l'utilisateur est valide mais le serveur refuse d'y répondre. Cela peut être dû à un manque d'autorisation pour accéder à la ressource demandée. Plusieurs scénarios peuvent mener à ce problème :

• Permissions de fichiers : si le serveur ne dispose pas des autorisations suffisantes pour accéder au fichier demandé, cela peut entraîner une erreur 403. Les correctifs possibles consistent à vérifier que le serveur tente d’accéder au fichier d’index du serveur web, le processus de travail détenu par www-data l’utilisateur, et que le fichier d’index est situé au bon endroit (dans le cas de Nginx, il s’agit de /usr/share/nginx/html/index.html).

• .htaccess : les serveurs web utilisent le .htaccess fichier pour implémenter diverses fonctionnalités de sécurité, par exemple, le filtrage d’adresses ou de plages IP spécifiques. Un correctif possible consiste à vérifier que l’adresse IP d’où provient la requête HTTP n’est pas bloquée.

• Le fichier n’existe pas : si la requête tente d’accéder à un emplacement qui n’a pas de fichier d’index par défaut et que le listage des répertoires n’est pas activé, le serveur renverra l’erreur 403. Dans une telle situation, un correctif possible consiste à ajuster la configuration du serveur pour autoriser le listage des répertoires.

Le code d’erreur 404 (Non trouvé) signifie que l’utilisateur a pu se connecter avec succès au serveur web mais n’a pas pu localiser la ressource demandée. Cette erreur peut apparaître dans plusieurs situations. Voici quelques actions de dépannage possibles :

• Vérifiez s’il n’y a pas d’erreur typographique potentielle dans le lien qui a dirigé l’utilisateur vers la ressource du serveur.

• L’utilisateur a pu mal saisir l’URL. Vérifiez si c’est le cas et corrigez-la si nécessaire.

• Vérifiez l’existence du fichier sur le serveur. A-t-il été déplacé ou supprimé du serveur ?

• Le serveur est peut-être configuré avec un mauvais emplacement racine des documents (document root). Vérifiez cela et corrigez-le si nécessaire.

• Le processus de travail du serveur web appartenant à l’utilisateur a-t-il l’autorisation de parcourir le fichier demandé ? Notez que l’accès à un répertoire nécessite à la fois des autorisations de lecture et d’exécution.

• La ressource est-elle un lien symbolique ? Dans ce cas, le serveur doit être configuré pour suivre les liens symboliques.

2. Erreurs de serveur courantes

Le code d’erreur 500 (Erreur interne du serveur) se produit lorsque le serveur n’est pas en mesure de traiter la requête pour des raisons inconnues. Dans certaines situations, le serveur signalera l’erreur 500 lorsqu’un code d’erreur 5xx plus spécifique serait approprié.

L’une des sources les plus courantes de l’erreur 500 est un serveur mal configuré, par exemple, un fichier .htaccess malformé. Cela peut également se produire s’il manque des paquets, par exemple, si l’on tente d’exécuter du code PHP sans que PHP soit installé sur le système.

Le code d’erreur 502 (Mauvaise passerelle) indique que le serveur est un proxy ou une passerelle et qu’il ne peut pas obtenir de réponse valide de la part du serveur d’arrière-plan (responsable du traitement effectif de la requête). Si le serveur est un proxy inverse, par exemple un répartiteur de charge, il y a plusieurs éléments différents à vérifier :

• Les serveurs d’arrière-plan sont opérationnels.

• Le proxy inverse est correctement configuré (avec les spécifications d’arrière-plan appropriées).

• La connexion entre le proxy inverse et le serveur d’arrière-plan est saine. Si les serveurs peuvent communiquer en utilisant différents ports, le pare-feu doit alors autoriser la connexion à ces ports.

• Si l’application web est configurée pour utiliser un socket, assurez-vous que le socket existe au bon endroit avec les autorisations appropriées.

Le code d’erreur 503 (Service indisponible) indique que le serveur subit une surcharge ou est actuellement en maintenance. Cela implique que le serveur devrait redevenir disponible à un moment donné.

Si le serveur n’est pas en maintenance, cela indique qu’il ne dispose pas des ressources matérielles nécessaires (puissance de traitement, mémoire, etc.) pour gérer les requêtes entrantes. Dans ce cas, le serveur doit être configuré pour autoriser plus d’utilisateurs ou allouer plus de ressources.

Le code d’erreur 504 (Dépassement du délai de la passerelle) indique que le serveur est un proxy ou un serveur de passerelle et qu’il n’a pas reçu de réponse de l’arrière-plan dans le délai imparti. Plusieurs situations peuvent conduire à ce problème :

• Une mauvaise connexion réseau entre les serveurs.

• Le serveur d’arrière-plan fonctionne trop lentement (en raison de problèmes de performances).

• La limite de temps d’attente (timeout) du serveur de passerelle/proxy est trop stricte.

Réflexions finales

Ce guide traite des codes d'erreur HTTP, en particulier de certains des plus courants. Il décrit la signification de ces codes et propose des suggestions d'actions de dépannage potentielles. Grâce à ces connaissances, vous disposez désormais d'une base solide pour résoudre les problèmes liés à vos serveurs web ou à vos applications.

Il ne s'agit que d'une liste restreinte des codes d'état HTTP les plus populaires. Pour obtenir une liste complète de tous les codes d'état HTTP, consultez les codes d'état HTTP sur Wikipédia. Vous pouvez également consulter notre tutoriel sur Proxying HTTP Nginx, équilibrage de charge, mise en mémoire tampon et mise en cache : un aperçu.

Bonne informatique !