400 Bad Request

Verwendung

Trifft ein 400-Bad-Request-Fehler ein, liegt es am Client, den Nachrichtenrumpf zu prüfen, um mehr über das Fehlschlagen zu erfahren. Der Server liefert ausreichend Details, damit der Client das Problem beheben kann. Häufige Gründe für eine 400-Bad-Request-Antwort sind:

Treten diese Fehler auf, kann der Client die URL noch einmal überprüfen, die Browser-Cookies löschen oder eine übergroße Datei vor der erneuten Übertragung komprimieren.

Hinweis

400er-Fehler sind Client-Fehler (die Anfrage ist fehlerhaft aufgebaut), während 500er-Fehler Server-Fehlfunktionen sind (der Server ist bei der Verarbeitung einer gültigen Anfrage gescheitert). Ein 400 ist nicht vorübergehend. Dieselbe Anfrage erneut zu senden erzeugt denselben Fehler. Der Client muss die Anfrage korrigieren, bevor er es erneut versucht. Browser-Erweiterungen oder Adware, die fehlerhafte Header einschleusen, sind eine häufige Ursache für unerwartete 400er-Fehler. Das Deaktivieren von Erweiterungen hilft bei der Diagnose des Problems.

SEO-Auswirkung

Suchmaschinen wie Google indexieren keine URL, die den Status 400 zurückgibt. Zuvor indexierte URLs, die diesen Statuscode zurückgeben, werden aus den Suchergebnissen entfernt. Seiten, die diesen Code zurückgeben, verbrauchen kein Crawl-Budget.

Beispiel

Der Client fordert eine Ressource an, deren Pfad geschweifte Klammern enthält. Diese sind in einer URL nicht zulässig, daher antwortet der Server mit 400 Bad Request.

Anfrage

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

Antwort

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>

Behebung

Ein 400 Bad Request bedeutet, dass der Server die Anfrage wegen eines clientseitigen Formatierungsproblems abgelehnt hat.

Prüfen Sie die URL auf Kodierungsfehler. Sonderzeichen wie geschweifte Klammern, Leerzeichen oder Nicht-ASCII-Zeichen müssen prozentkodiert werden. Untersuchen Sie den vollständigen Anfragepfad und die Query-Zeichenkette. Lassen Sie die URL durch einen Validator laufen, um unzulässige Bytefolgen zu finden.

Validieren Sie die Anfrage-Header. Ein fehlerhafter Host-Header, ein übergroßer Cookie-Header oder ein fehlender Pflicht-Header löst diesen Fehler aus. Vergleichen Sie die Header mit der API-Spezifikation. Verwenden Sie die Browser-DevTools (Tab Network) oder curl -v, um die mit der Anfrage gesendeten Roh-Header zu untersuchen.

Untersuchen Sie den Anfragerumpf auf Syntaxfehler. Ungültiges JSON, defekte Formularkodierung oder eine Diskrepanz zwischen dem Header Content-Type und dem tatsächlichen Rumpfformat führen zur Ablehnung. Validieren Sie JSON-Nutzlasten vor dem Senden mit einem Linter.

Leeren Sie Browser-Cache und Cookies. Beschädigte oder abgelaufene Cookies erzeugen fehlerhafte Anfrage-Header. Große Cookie-Werte, die die Puffergrenzen des Servers überschreiten, sind ein häufiger Auslöser. Löschen Sie die gespeicherten Daten und versuchen Sie es erneut.

Gleichen Sie Content-Length mit der tatsächlichen Rumpfgröße ab. Eine Abweichung zwischen der angegebenen und der übertragenen Byteanzahl führt zu einer Bad-Request-Antwort.

Prüfen Sie die serverseitigen Größenbeschränkungen. nginx lehnt übergroße Header mit einem 400 ab, wenn sie den über large_client_header_buffers konfigurierten Puffer überschreiten (Standard: 4 Puffer zu je 8 KB). Erhöhen Sie den Wert in der nginx.conf:

large_client_header_buffers 4 16k;

Apache erzwingt LimitRequestFieldSize (Standard 8190 Bytes) und LimitRequestLine. Erhöhen Sie diese Werte in der Serverkonfiguration oder im virtuellen Host:

LimitRequestFieldSize 16384
LimitRequestLine 16384

Aktivieren Sie das Debug-Logging, um die genaue Ursache zu ermitteln. nginx protokolliert den Ablehnungsgrund auf der Stufe info. Setzen Sie error_log auf info und sehen Sie sich /var/log/nginx/error.log an. Apache protokolliert den beanstandeten Header-Namen bei LogLevel info im Fehlerprotokoll.

Untersuchen Sie die Header-Weiterleitung des Reverse-Proxys. Wenn nginx oder Apache als Reverse-Proxy arbeitet, führt ein falsch gesetzter Header Host, X-Forwarded-For oder X-Real-IP dazu, dass das Backend die Anfrage ablehnt. Stellen Sie sicher, dass die proxy_set_header-Direktiven gültige Werte durchreichen.

Code-Referenzen

.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