Was bedeutet ein 400 Bad Request und wessen Schuld ist es

Ein 400 Bad Request ist der Server, der sich weigert, es überhaupt zu versuchen. Er hat sich angesehen, was angekommen ist, entschieden, dass es fehlerhaft genug war, dass es keinen Sinn hatte, weiter zu parsen, und den einen Code zurückgeschickt, der bedeutet: “Das ist keine Anfrage, die ich lesen kann.”

Das ist eine andere Art der Ablehnung als bei den meisten Fehlern ringsum. Ein 404 bedeutet, der Server hat Sie perfekt verstanden und hat nichts unter dieser Adresse. Ein 403 bedeutet, er hat Sie verstanden und wird es nicht tun. Ein 400 bedeutet, er ist nie so weit gekommen, zu verstehen: die Syntax war falsch, ein Header war fehlerhaft, der Body hatte nicht die Form, die der Endpunkt deklariert hat. Die Anfrage ist gescheitert, bevor die Frage überhaupt gestellt wurde.

Das Wort “Client” leistet hier viel Arbeit

Jede Referenz wird Ihnen sagen, dass ein 4xx ein Client-Fehler ist, und das ist technisch wahr und praktisch irreführend. Der Client sind nicht Sie. Der Client ist die Software, die die Anfrage zusammengesetzt hat, und auf einer modernen Website ist das fast immer das JavaScript der Seite selbst.

Ein 400 auf einer Website, die Sie besuchen, bedeutet also meist, dass deren Frontend eine Anfrage gebaut hat, die deren Backend nicht akzeptieren wollte. Irgendjemandes Formular-Serialisierer hat ein Datum im falschen Format geschickt, ein Fetch-Aufruf hat JSON gepostet, ohne zu sagen, dass es JSON war, ein Query-String hat ein Zeichen getragen, das niemand maskiert hat. Der Statuscode gibt dem Client die Schuld, und der Client ist ihrer.

Das ist wichtig, weil es den Rat umkehrt, der zu den meisten Fehlern gehört. Bei einem 500 liegt die Schuld offensichtlich beim Server, und Sie können nichts tun. Bei einem 400 klingt die Schuld nach Ihrer, was Leute zwanzig Minuten lang Caches leeren und URLs neu tippen lässt, wegen eines Fehlers, den sie gar nicht verursacht haben konnten.

Die 4xx-Familie, die ständig verwechselt wird

400 Bad Request

Die Anfrage war fehlerhaft. Der Server konnte sie nicht gut genug parsen, um darauf zu reagieren, also wurde nie berücksichtigt, wer Sie sind oder wonach Sie gefragt haben

401 Unauthorized

Die Anfrage war in Ordnung. Sie haben nicht nachgewiesen, wer Sie sind, und der Server will Anmeldedaten

403 Forbidden

Die Anfrage war in Ordnung, und er weiß, wer Sie sind. Das ist Ihnen nicht erlaubt

404 Not Found

Die Anfrage war in Ordnung, und unter dieser Adresse ist nichts

Die Zeile, die es festzuhalten lohnt, ist, dass nur der 400 von der Form der Anfrage handelt. Die anderen drei beschreiben alle eine wohlgeformte Anfrage, die weiter innen auf eine Wand trifft, weshalb 401 und 403 so oft miteinander vertauscht werden und keiner von beiden je mit einem 400 verwechselt wird. Wenn Sie einen 400 bekommen, hören Sie auf, nach Berechtigungen zu fragen, und fangen Sie an zu fragen, was tatsächlich gesendet wurde.

Der eine 400, den Sie wirklich selbst beheben können

Es gibt eine Ausnahme, und sie ist häufig genug, um sie zu kennen, bevor Sie die Website als kaputt abschreiben: eine Anfrage, deren Header zu groß sind.

Cookies sind Header. Eine Website, die ein paar Jahre davon angesammelt hat, oder ein Login-Ablauf, der oft genug wiederholt wurde, um Sitzungszustand aufzustapeln, kann den Header-Block über das Limit drücken, das der Server bereit ist zu lesen. Die meisten Server antworten darauf mit einem 400, manchmal mit einer Seite, auf der “Request Header Or Cookie Too Large” steht, und oft mit gar nichts.

Das Erkennungszeichen ist, dass es Ihnen auf einer Website folgt und auf keiner anderen, einen Reload überlebt und in einem privaten Fenster sofort verschwindet. Wenn das beschreibt, was Sie sehen, behebt das Löschen der Cookies dieser Website es, und es ist der einzige 400, bei dem die üblichen Hausmittel die tatsächliche Antwort sind. Wenn ein privates Fenster denselben 400 zeigt, ist es das nicht, und kein noch so gründliches Löschen wird daran etwas ändern.

Wenn es Ihre Website ist

Die Antwort, die der Benutzer bekam, ist bewusst nahezu leer, also liegt die Ursache in dem, was gesendet wurde, und nicht in dem, was zurückkam. Eine Handvoll Dinge macht die meisten davon aus.

Ein fehlerhafter oder vertippter Body. Ein POST, der JSON trägt, das nicht parst, oder das parst und nicht zu dem Schema passt, gegen das der Endpunkt validiert. Oft ein Feld, das null ist, wo die API einen String deklariert hat, oder eine Zahl, die als "12" ankommt, weil ein Formular-Serialisierer alles in Strings verwandelt.

Ein fehlender oder falscher Content-Type. Ein Body, den der Server gerne akzeptieren würde, gesendet ohne zu sagen, was er ist, oder als text/plain etikettiert, wenn der Parser application/json will. Die Anfrage ist wohlgeformt anzusehen und unlesbar für das, was sie lesen muss.

Etwas in der URL, das nie maskiert wurde. Ein rohes Leerzeichen, ein verirrtes %, das nicht der Anfang einer Escape-Sequenz ist, ein Query-Parameter, der eine eigene URL mit eigenem & trägt. Manche davon werden vom Webserver abgelehnt, bevor Ihre Anwendung sie je sieht, weshalb sie keine Spur in Ihrem Anwendungslog hinterlassen.

Header, die der Proxy nicht nimmt. Der Cookie-Fall von oben, aber auch ein übergroßer Authorization-Header oder ein Header, der einen Zeilenumbruch trägt. Diese werden meist am Rand abgelehnt, von nginx oder einem CDN, und der 400, der zurückkommt, ist der dieses Proxys, nicht Ihrer.

Diese letzte Gruppe ist der Grund, warum ein 400 von innen wirklich unsichtbar sein kann. Wenn die Ablehnung geschah, bevor die Anfrage Ihren Code erreichte, gibt es keine Zeile in Ihrem Anwendungslog zu finden, und Sie können einen Nachmittag damit verbringen, einen Fehler an einer Stelle zu suchen, die er nie erreichen durfte.

Warum ein 400 im Nachhinein schwer zu verfolgen ist

Ein 400 ist vollständig eine Aussage über eine Anfrage, die nicht mehr existiert. Wenn Ihnen jemand davon erzählt, ist das fehlerhafte Ding längst weg: Sie haben einen Statuscode, eine ungefähre Zeit und eine URL, die wahrscheinlich einwandfrei funktioniert, wenn Sie sie selbst eintippen, weil das, was kaputt war, in einem Header oder einem Body steckte, den Sie in der Adressleiste nicht sehen können.

Es zu reproduzieren bedeutet, die exakte Anfrage zu rekonstruieren, was bedeutet, zu wissen, was die Seite gesendet hat, und das ist genau das Eine, was ein Screenshot einer Fehlerseite Ihnen nicht sagen kann.

Das Netzwerkprotokoll ist hier der ganze Punkt. Es enthält die Anfrage, die den 400 bekam, mit ihrer Methode, ihren Headern und ihrem Body, und das ist genau das Material, worüber sich ein 400 beschwert. Wer den Bericht aufnimmt, kann lesen, was gesendet wurde, statt es zu erraten, und das ist meist die gesamte Untersuchung.

In einem Absatz

Ein 400 Bad Request bedeutet, dass der Server nicht parsen konnte, was ankam, und aufgab, bevor er es berücksichtigte, was ihn zum einzigen 4xx macht, der von der Form der Anfrage handelt statt von Berechtigung oder Existenz. Er heißt Client-Fehler, aber der Client ist meist das JavaScript der Website selbst, es gibt als Besucher also im Allgemeinen nichts zu beheben, mit einer echten Ausnahme: ein Cookie- oder Header-Block, der zu groß geworden ist, was ein privates Fenster in Sekunden bestätigt. Wenn es Ihre Website ist, schauen Sie auf das, was gesendet wurde: ein nicht parsbarer Body, ein fehlender Content-Type, eine nicht maskierte URL oder ein Header, den Ihr Proxy ablehnte, bevor Ihr Code je lief.