400 Bad Request

Utilisation

Lorsqu’une erreur 400 Bad Request survient, il revient au client d’examiner le corps du message pour en apprendre davantage sur l’échec. Le serveur renvoie suffisamment de détails pour que le client puisse corriger le problème. Les raisons courantes d’une réponse 400 Bad Request sont les suivantes :

Face à ces erreurs, le client peut revérifier l’URL, effacer les Cookies du navigateur ou compresser un fichier trop volumineux avant de réémettre la requête.

Remarque

Les erreurs 400 sont des erreurs client (la requête est malformée), tandis que les erreurs 500 sont des défaillances serveur (le serveur a échoué en traitant une requête valide). Une 400 n’est pas temporaire. Réémettre la même requête produit la même erreur. Le client doit corriger la requête avant de réessayer. Les extensions de navigateur ou les logiciels publicitaires qui injectent des en-têtes malformés sont une cause fréquente d’erreurs 400 inattendues. Désactiver les extensions aide à diagnostiquer le problème.

Impact SEO

Les moteurs de recherche comme Google n’indexent pas une URL renvoyant un statut 400. Les URL précédemment indexées qui renvoient ce code de statut sont retirées des résultats de recherche. Les pages renvoyant ce code ne gaspillent pas de budget d’exploration.

Exemple

Le client demande une ressource dont le chemin contient des accolades. Celles-ci ne sont pas valides dans une URL, le serveur répond donc 400 Bad Request.

Requête

GET /index{15}.html HTTP/1.1
Host: example.com

Réponse

HTTP/1.1 400 Bad Request
Content-Type: text/html; charset=UTF-8
Content-Length: 131

<html>
  <head>
    <title>Malformed URL</title>
  </head>
  <body>
    <p>Invalid characters in HTTP request</p>
  </body>
</html>

Comment corriger

Une 400 Bad Request signifie que le serveur a rejeté la requête en raison d’un problème de formatage côté client.

Vérifiez l’URL à la recherche d’erreurs d’encodage. Les caractères spéciaux comme les accolades, les espaces ou les caractères non ASCII doivent être encodés en pourcentage. Inspectez l’intégralité du chemin de la requête et de la chaîne de requête. Soumettez l’URL à un validateur pour détecter les séquences d’octets illégales.

Validez les en-têtes de requête. Un en-tête Host malformé, un en-tête Cookie surdimensionné ou l’absence d’un en-tête obligatoire déclenche cette erreur. Comparez les en-têtes à la spécification de l’API. Utilisez les DevTools du navigateur (onglet Network) ou curl -v pour inspecter les en-têtes bruts envoyés avec la requête.

Inspectez le corps de la requête à la recherche d’erreurs de syntaxe. Un JSON invalide, un encodage de formulaire défectueux ou une incohérence entre l’en-tête Content-Type et le format réel du corps entraîne un rejet. Validez les charges utiles JSON avec un linter avant de les envoyer.

Videz le cache et les Cookies du navigateur. Des Cookies corrompus ou expirés produisent des en-têtes de requête malformés. Les valeurs de cookie volumineuses qui dépassent les limites des tampons du serveur sont un déclencheur fréquent. Effacez les données stockées et réessayez.

Vérifiez Content-Length par rapport à la taille réelle du corps. Un écart entre le nombre d’octets déclaré et le nombre transmis se traduit par une réponse de requête incorrecte.

Contrôlez les limites de taille côté serveur. nginx rejette avec une 400 les en-têtes trop volumineux lorsqu’ils dépassent le tampon configuré par large_client_header_buffers (par défaut : 4 tampons de 8 Ko). Augmentez la valeur dans nginx.conf :

large_client_header_buffers 4 16k;

Apache applique LimitRequestFieldSize (8190 octets par défaut) et LimitRequestLine. Relevez ces valeurs dans la configuration du serveur ou de l’hôte virtuel :

LimitRequestFieldSize 16384
LimitRequestLine 16384

Activez la journalisation de débogage pour identifier la cause exacte. nginx journalise le motif du rejet au niveau info. Réglez error_log sur info et examinez /var/log/nginx/error.log. Apache consigne le nom de l’en-tête fautif dans le journal d’erreurs avec LogLevel info.

Inspectez la transmission des en-têtes par le proxy inverse. Lorsque nginx ou Apache fonctionne en proxy inverse, un en-tête Host, X-Forwarded-For ou X-Real-IP mal défini amène le backend à rejeter la requête. Vérifiez que les directives proxy_set_header transmettent des valeurs valides.

Références de code

.NET

HttpStatusCode.BadRequest

Rust

http::StatusCode::BAD_REQUEST

Rails

:bad_request

http.StatusBadRequest

Symfony

Response::HTTP_BAD_REQUEST

Python3.5+

http.HTTPStatus.BAD_REQUEST

Java

java.net.HttpURLConnection.HTTP_BAD_REQUEST

Apache HttpComponents Core

org.apache.hc.core5.http.HttpStatus.SC_BAD_REQUEST

Angular

@angular/common/http/HttpStatusCode.BadRequest