HTTP 431: Request Header Fields Too Large durch aufgeblähte Cookies
Statuscode 431 im Browser? Der Anfrage-Kopf ist zu groß, fast immer wegen zu vieler Cookies. So findest du den Übeltäter und wirst ihn los.
Aufwand:
ca. 25 Min.
Voraussetzung:
Browser mit Entwicklerwerkzeugen, curl, Zugriff auf die Serverkonfiguration
Das Symptom
Eine Seite, die eben noch lief, antwortet plötzlich mit 431 Request Header
Fields Too Large – oder, je nach Server, mit einem nackten 400. Andere Geräte
im selben Haushalt kommen problemlos auf dieselbe Adresse, ein privates Fenster
ebenfalls. Auffällig oft trifft es genau einen Nutzer, gern denjenigen mit den
meisten Berechtigungen, und ausgerechnet der kann es niemandem vorführen.
Die „Layer 8“-Wahrheit
Der Server ist gesund, die Leitung ist gesund, und dein Browser hat schlicht zu
viel zu erzählen. Jede Anfrage besteht aus einem Kopf und einem Inhalt, und der
Kopf hat eine Obergrenze. RFC 6585 beschreibt den Fall nüchtern: Der Server ist
nicht bereit, die Anfrage zu bearbeiten, weil deren Header-Felder zu groß sind –
und die Anfrage darf nach dem Verkleinern erneut geschickt werden. Der Kopf ist
dabei fast nie durch etwas Exotisches aufgebläht, sondern durch das eine Feld,
das über Monate unbemerkt wächst: Cookie. Jedes Anmeldesystem, jedes
Analysewerkzeug, jede Testumgebung legt dort etwas ab, und der Browser hängt
brav alles an jede einzelne Anfrage an dieselbe Domain. Irgendwann reicht der
Puffer nicht mehr, und der Server macht das einzig Vernünftige: Er lehnt ab,
statt beliebig viel zu lesen. Der Reflex, am Server den Puffer hochzudrehen,
funktioniert – nur ist es die Lösung mit der kürzesten Haltbarkeit, denn der
Cookie wächst weiter und der nächste Proxy im Weg hat seine eigene Grenze. Der
Unterschied zwischen Erster Hilfe und Behebung ist hier besonders sichtbar: Die
Puffergröße kauft dir den Nachmittag, die Aufräumaktion in den Cookies kauft dir
das Jahr.
Die echte, verifizierte Lösung
1000 % faktenbasiert. Jeder Befehl ist real, jeder Pfad existiert. Schritt für Schritt:
1.
Den Verdacht in zehn Sekunden bestätigen
Dieselbe Adresse in einem privaten Fenster oder einem anderen Browserprofil öffnen. Läuft sie dort einwandfrei, liegt es nicht am Server, sondern an dem, was dein Browser für diese Domain gespeichert hat. Das ist der schnellste Test überhaupt und erspart eine halbe Stunde Serversuche.
2.
Den tatsächlichen Umfang des Anfrage-Kopfes messen
In den Entwicklerwerkzeugen des Browsers unter Netzwerk die fehlgeschlagene Anfrage anklicken und die Anfrage-Header ansehen. Interessant ist die Zeile Cookie: Wenn sie mehrere Kilobyte lang ist, ist der Fall geklärt. Zum Gegenprüfen lässt sich eine Anfrage mit definiert großem Cookie auch von Hand schicken.
Nicht den gesamten Browser leeren, sondern nur die Cookies der betroffenen Domain – sonst bist du überall abgemeldet und weißt trotzdem nicht, was es war. In den Entwicklerwerkzeugen unter Anwendung beziehungsweise Speicher lassen sich die Einträge einzeln entfernen. Danach neu anmelden und beobachten, wie schnell der Kopf wieder wächst.
4.
Die Serverseite auslesen, statt zu raten
Im Fehlerprotokoll des Servers steht, welche Anfrage abgewiesen wurde. Bei nginx landen abgewiesene Anfragen mit zu langen Kopfzeilen als Fehlermeldung im error.log, zusammen mit der Client-Adresse und der angefragten Adresse.
Die Direktive large_client_header_buffers steht laut nginx-Dokumentation standardmäßig auf 4 8k und gilt im http- oder server-Kontext; die Puffer werden nur bei Bedarf belegt. Ein einzelnes Header-Feld darf die Größe eines Puffers nicht überschreiten – der zweite Wert ist also die eigentliche Grenze für eine lange Cookie-Zeile. Nach der Änderung erst die Konfiguration prüfen, dann neu laden.
# in nginx.conf, Kontext http oder server
large_client_header_buffers 4 16k;
sudo nginx -t
sudo systemctl reload nginx
6.
Die Ursache beseitigen, nicht nur die Grenze verschieben
Danach der eigentliche Teil: Wer schreibt so viel in den Cookie? Sitzungsdaten gehören in den Sitzungsspeicher des Servers, im Cookie steht nur die Kennung. Alte Cookies bekommen ein Ablaufdatum, Testsysteme setzen keine Cookies auf die Hauptdomain, und Anmeldesysteme, die Berechtigungslisten mitschicken, werden auf eine Kennung umgestellt. Sonst kommt derselbe Fehler in einem halben Jahr wieder – dann mit größerem Puffer und größerem Cookie.
Häufige Fragen (FAQ)
?Was bedeutet 431 genau, und wer schickt ihn?
RFC 6585 definiert den Code in Abschnitt 5 so: „The 431 status code indicates that the server is unwilling to process the request because its header fields are too large. The request MAY be resubmitted after reducing the size of the request header fields.“ Der Server verweigert also die Bearbeitung, weil der Kopf der Anfrage zu groß ist, nicht ihr Inhalt. Laut RFC gilt das sowohl für die Summe aller Header-Felder als auch für ein einzelnes zu großes Feld – im zweiten Fall soll die Antwort benennen, welches Feld zu groß war. Und: „Responses with the 431 status code MUST NOT be stored by a cache.“ Ein 431 ist deshalb kein Zustand, den ein Zwischenspeicher konservieren dürfte.
?Warum sind fast immer Cookies schuld?
Weil Cookies das einzige Header-Feld sind, das unbegrenzt wächst, ohne dass jemand es merkt. Der Browser hängt bei jeder Anfrage an die Domain alle passenden Cookies an – auch die von Tracking-Werkzeugen, Testsystemen, alten Sitzungen und abgebrochenen Anmeldevorgängen. Besonders unangenehm sind Anmeldesysteme, die Berechtigungen in den Cookie schreiben: Je mehr Gruppen ein Nutzer hat, desto größer der Kopf. Deshalb trifft der Fehler regelmäßig genau eine Person im Team – die mit den meisten Rechten – und niemand kann ihn nachstellen.
?Warum sehe ich unter nginx ein 400 statt eines 431?
Weil nginx an dieser Stelle andere Codes verwendet. Die Dokumentation zu large_client_header_buffers sagt es wörtlich: „A request line cannot exceed the size of one buffer, or the 414 (Request-URI Too Large) error is returned to the client. A request header field cannot exceed the size of one buffer as well, or the 400 (Bad Request) error is returned to the client.“ Ein zu langes Cookie-Feld erzeugt dort also ein 400, kein 431. Die Ursache ist dieselbe, nur die Nummer nicht – wer nach der falschen Zahl sucht, findet nichts.
?Ich habe den Puffer am Server vergrößert, und es geht wieder. Fertig?
Nur vorläufig. Ein größerer Puffer verschiebt die Grenze, er entfernt sie nicht – der Cookie, der heute knapp hineinpasst, wächst weiter. Dazu kommt: Kommt vor deinem Server noch ein Reverse Proxy oder ein CDN, hat das Ding seine eigenen Grenzen, und die kennst du nicht. Der Puffer ist die Erste Hilfe, die Ursache ist der aufgeblähte Kopf. Sitzungsdaten gehören auf den Server, im Cookie steht idealerweise nur eine Kennung.
Belege
Diese Seite ist gegen die folgenden Primärquellen geprüft – Hersteller, Standard oder Gesetzestext. Wer es nicht glaubt, muss es nicht: Da steht, wo es nachzulesen ist.
Der Browser meldet ERR_TOO_MANY_REDIRECTS und die Seite lädt nie fertig? Eine Weiterleitungsschleife ist schuld. So findest du sie auf Client und Server.
nginx liefert 502 Bad Gateway? Der Upstream antwortet nicht wie erwartet. So findest du Dienst-, Timeout- und Berechtigungsursachen und reparierst sie.
nginx liefert 504 Gateway Timeout? Der Upstream antwortet nicht rechtzeitig, bevor nginx aufgibt. So findest du die Ursache und setzt Timeouts sinnvoll.