Guide complet des codes d'état HTTP : série 400

Les problèmes avec un client user-agent peuvent aller de requêtes vers des ressources qui ne sont plus disponibles (à cause d'une faute de frappe dans un URI) jusqu'à la réaction du serveur à des requêtes correspondant à la signature d'une attaque.

Le plus courant est le 404. Le 404 Not Found est renvoyé quand un client demande une ressource que le serveur web ne peut pas trouver :

Passons en revue les codes de réponse de la série 400 les plus courants et les plus intéressants, un peu plus en détail.

400 Bad Request

Le 400 Bad Request est (en général) le résultat d'un user-agent qui envoie dans la requête quelque chose que le serveur web n'a pas pu traiter. Générons un 400 Bad Request pour comprendre ce qui peut provoquer cette erreur.

Nous allons faire à l'ancienne sous Linux et utiliser un outil appelé netcat. Netcat peut servir à envoyer des données brutes à travers des sockets. Après tout, les requêtes HTTP/1.1 ne sont que cela : du texte brut.

D'abord, envoyons une requête HEAD légitime à google :

Forçons un 400 Bad Request :

image: src /blog/wp-content/uploads/2017/12/3CEEAuo-e1513087453173.jpg (unchanged); alt: Mauvaise requête forcée produisant un 400

Nous avons envoyé à dessein une requête que le serveur ne pouvait pas comprendre. Regardons la méthode de requête utilisée :

$ nc www.google.com 80 BAD / HTTP/1,1 Host: www.google.com

Le serveur web n'a pas pu traiter la méthode : BAD

Il est improbable qu'un navigateur web moderne envoie des requêtes mal formées comme celle ci-dessus. Toutefois, si vous utilisez une application HTTP développée sur mesure, comme un web scraper, c'est le moment de déboguer.

Ces étapes résolvent les erreurs 400 les plus courantes.

1. Vérifiez l'URL

Si vous cliquez sur un lien, il est tout à fait possible que l'auteur de la page ait fait une faute de frappe. Examinez l'URL entière, en prêtant une attention particulière au chemin, au titre du document et à la chaîne de requête.

2. Effacez tous les cookies et le cache

Effacer les cookies et le cache corrige beaucoup d'erreurs 400, et c'est aussi un bon premier pas pour beaucoup d'autres codes d'état 400.

1. effacez tous les cookies et l'historique de navigation
2. réessayez la requête

Dans Chrome, Edge et Firefox, l'option se trouve dans les paramètres du navigateur sous Confidentialité, généralement appelée « Effacer les données de navigation ». Les noms des menus varient selon la version. Effacer les cookies du seul site concerné suffit souvent.

Effacer tous les cookies et l'historique de navigation garantit que tout ce qui est en cache ou corrompu (comme les cookies) a disparu. Cela corrige souvent un 400 Bad Request.

3. Taille du fichier téléversé

Le problème pourrait très bien être un script back-end lui-même, le téléversement d'un fichier trop gros ou d'un fichier avec un mauvais type de média.

1. Si le 400 bad request apparaît pendant le téléversement d'un fichier, essayez un fichier plus petit.
2. Assurez-vous que le type de fichier est accepté.
3. Si vous téléversez une image, essayez les deux formats, jpeg et png.
4. Si vous téléversez un document, le texte brut et les formats bureautiques courants sont en général permis.

4. En-têtes mal formés

Des en-têtes mal formés seraient un problème d'assez bas niveau et pourraient très bien laisser l'application web elle-même en faute.

Les outils de développement intégrés à tout navigateur moderne (l'onglet Network) nous permettent d'observer toute la transaction HTTP à la recherche de quoi que ce soit d'inhabituel.

5. Mettez à jour votre navigateur et désactivez les plugins

Si votre navigateur n'est pas à jour, il pourrait très bien envoyer des en-têtes et des requêtes dépassés.

Essayez aussi de retirer ou de désactiver tous les plugins et extensions. Essayer la même requête dans un autre navigateur peut aussi aider à isoler le problème.

6. Essayez de vous déconnecter

Si vous utilisez une application web avec authentification des utilisateurs et sessions, essayez de vous déconnecter puis d'effacer le cache du navigateur.

(hr)

401 Unauthorized

Le 401 Unauthorized est renvoyé quand un serveur web demande des identifiants pour un document protégé.

403 Forbidden

Le 403 Forbidden est en général l'une de quatre choses :

• le listage de répertoire n'est pas permis
• l'utilisateur actuellement authentifié n'a pas les permissions suffisantes
• le processus du serveur web a des permissions insuffisantes
• l'adresse qui fait la demande a été bannie

Listage de répertoire non permis

Ici, le serveur web n'autorise pas les listages de répertoire pour les utilisateurs non authentifiés. Le correctif le plus simple est de placer un fichier index dans le répertoire. Autrement, les listages de répertoire pour les utilisateurs non authentifiés devront être explicitement configurés.

L'utilisateur authentifié n'a pas les permissions

La meilleure méthode dans ce cas est de créer un groupe pour tous les utilisateurs qui ont besoin d'accéder à une ressource. Donnez à ce groupe les permissions nécessaires au niveau du système de fichiers. Puis ajoutez les utilisateurs autorisés au groupe.

Le processus du serveur web n'a pas les permissions suffisantes

image: src /blog/wp-content/uploads/2017/12/XSkGl4h-e1513087253567.jpg (unchanged); alt: Accès refusé

Nous ne pouvons pas accéder à la page test.php dans la racine web, dans /var/www/html. Sur RHEL et ses dérivés (Oracle Linux, AlmaLinux, Rocky Linux), il y a deux choses à vérifier : les permissions de fichiers classiques et le contexte SELinux.

D'abord, vérifiez la propriété et les permissions :

# ls -ld /var/www/html/ drwx------. 3 root root 4096 Nov 24 03:47 /var/www/html/

Le répertoire appartient à l'utilisateur root et au groupe root sans accès pour quiconque d'autre, donc le processus du serveur web (utilisateur apache pour Apache httpd, nginx pour nginx) ne peut pas le lire. Donnez au groupe du serveur web un accès en lecture, sans écriture :

# chgrp -R apache /var/www/html # chmod 750 /var/www/html # chmod 640 /var/www/html/test.php # ls -ld /var/www/html/ drwxr-x---. 3 root apache 4096 Nov 24 03:47 /var/www/html/ # ls -l /var/www/html/test.php -rw-r-----. 1 root apache 91 Nov 16 06:52 /var/www/html/test.php

Ensuite, vérifiez le contexte SELinux. Les fichiers déplacés dans la racine web depuis ailleurs conservent leur ancien label, et SELinux bloque alors le serveur web même quand les permissions sont justes :

# ls -Z /var/www/html/test.php # restorecon -Rv /var/www/html

Le contenu sous /var/www/html doit porter le type httpd_sys_content_t. Corrigez le label avec restorecon. Ne désactivez jamais SELinux pour faire disparaître un 403.

Pour une bonne pratique de sécurité, le groupe du serveur web ne doit pas avoir de permissions d'écriture sur les fichiers et les dossiers. Là où un système de gestion de contenu a besoin d'écrire (un dossier uploads, par exemple), accordez l'accès en écriture à ce dossier seulement, et sur RHEL donnez-lui le type SELinux httpd_sys_rw_content_t.

Refuser les permissions d'écriture sur les fichiers et les dossiers peut offrir une couche de sécurité supplémentaire dans le cas où une faille de l'application web serait exploitée par un attaquant pour modifier du contenu, supprimer des fichiers ou en ajouter.

Dans un environnement de staging, mettez les développeurs dans le groupe du serveur web et donnez à ce groupe l'accès en écriture. Gardez la production en lecture seule.

Un autre scénario courant pour un état 403 Forbidden peut être une adresse IP ou une plage d'IP bannie dans un fichier .htaccess par l'administrateur du serveur.

404 Not Found

Le 404 Not Found signifie que le serveur web n'a pas pu trouver une ressource demandée. Face à une erreur 404, vous pouvez faire quelques choses :

• vérifiez l'orthographe de l'hôte, du domaine, du chemin et du document
• vérifiez la casse du fichier et du chemin. Les serveurs web Linux et Unix (sauf configuration contraire) distinguent en général la casse, la tradition étant d'utiliser tout en minuscules.
• utilisez Google pour trouver une URL alternative vers la ressource
• essayez une copie archivée de la page dans la Wayback Machine de l'Internet Archive

Utiliser les opérateurs de recherche avancée de Google

image: src /blog/wp-content/uploads/2017/12/KbnaNqB-e1513087331180.jpg (unchanged); alt: Google : trouver tous les fichiers PDF

Une requête comme celle ci-dessus, avec des opérateurs comme site: et filetype:, trouve souvent un document dont l'ancien lien renvoie maintenant un 404.

Si la page a été retirée, la Wayback Machine de l'Internet Archive peut encore en conserver une copie plus ancienne.

405 Method Not Allowed

Un 405 Method Not Allowed se présente quand on tente une méthode de requête non permise par le serveur web.

406 Not Acceptable

Le 406 Not Acceptable est renvoyé quand le serveur ne peut fournir la ressource dans aucun des types de contenu, encodages, langues ou jeux de caractères que le client déclare accepter.

Pour résoudre un 406, regardez les en-têtes de la requête dans les outils de développement de votre navigateur (onglet Network).

Les valeurs d'en-têtes envoyées par le client qui méritent une vérification comprennent :

• Accept
• Accept-Charset
• Accept-Encoding
• Accept-Language

Les navigateurs modernes le déclenchent rarement. Si le vôtre le fait, essayez de le mettre à niveau vers une version plus récente.

407 Proxy Authentication Required

Le 407 Proxy Authentication Required signifie en général que le user-agent doit fournir des identifiants pour accéder à un serveur proxy.

image: src /blog/wp-content/uploads/2017/12/GpVOCul.jpg (unchanged); alt: Fourniture d'identifiants de proxy sous Linux

408 Request Timeout

Le 408 signifie que le serveur a attendu trop longtemps que le client finisse d'envoyer sa requête. Il indique en général une connexion client lente ou instable plutôt qu'un problème de serveur.

429 Too Many Requests

Le 429 signifie en général qu'un rate limiting a été activé sur le serveur. Le rate limiting n'autorise qu'un certain nombre de requêtes dans un laps de temps donné.

Quand vous recevez 429 Too Many Requests, ralentissez. Le serveur peut envoyer un en-tête Retry-After qui dit combien de temps attendre avant de réessayer. Les clients et les scripts bien élevés le respectent et reculent.

451 Unavailable for Legal Reasons

Le 451 est renvoyé quand le serveur est légalement tenu de bloquer l'accès à une ressource, par exemple à la suite d'une décision de justice.