Summary

  • RFC 6265 beschreibt den Kreislauf: Der Server sendet Set-Cookie; der Browser gibt passende Name-Wert-Paare in späteren Anfragen als Cookie zurück. Server sollen wenige, kleine Cookies ausgeben.
  • RFC 6585 führte im April 2012 den Status 431 ein, wenn alle Request-Header zusammen oder ein einzelnes Feld zu groß sind. Nach einer Verkleinerung darf die Anfrage wiederholt werden; ein Cache darf die 431-Antwort nicht speichern.
  • Auch HTTP/2 und HTTP/3 erlauben dem Server, ein Feldpaket oder einen Header-Abschnitt oberhalb seiner Annahmegrenze mit 431 zurückzuweisen.

Das Gepäck stammt vom Empfänger

Eine Kundin besucht einen Onlineshop erneut. Der Browser fordert die Startseite an und bringt Cookie mit: Sitzung, Einstellungen und vielleicht mehrere Kennungen für Experimente. Der Shop hatte diese Werte bei früheren Besuchen setzen lassen. Nun misst ein Gateway oder Server die eingehenden Header und weist die Anfrage wegen ihrer Größe zurück. Statt der Seite kommt 431. Der Empfänger hat das Paket selbst gepackt und lässt den Boten nicht hinein.

Die Transportregel steht in RFC 6265 vom April 2011. Mit Set-Cookie übergibt ein Server dem User Agent Namen und Wert. Bei späteren Anfragen prüft der Browser Domain, Pfad und weitere Bedingungen und sendet passende Paare im Feld Cookie. Attribute für Geltungsbereich und Ablaufzeit werden nicht als Cookie-Paare zurückgesandt; Namen und Werte schon. Eine Entscheidung in einer Antwort wächst so zu einer wiederkehrenden Last auf jeder erfassten Route.

Abschnitt 6.1 nennt zwei Zahlen, die leicht in den falschen Topf geraten. Allgemeine Browser sollen mindestens 4096 Byte pro Cookie und mindestens 50 Cookies pro Domain speichern können. Im selben Abschnitt fordert die Spezifikation Server zu wenigen, kleinen Cookies auf, weil Cookie mit jeder passenden Anfrage übertragen wird. Die 4096 Byte beschreiben die Mindestfähigkeit des Browsers zur Speicherung. Sie versprechen keine gemeinsame Annahmegrenze für den gesamten Request-Header bei allen Gateways und Anwendungen. Was eine Seite dem Browser zumutet, kann ihren eigenen Einlass überfordern.

Die Ablehnung bekam eine Nummer

RFC 6585 ergänzte HTTP im April 2012 um vier Statuscodes. 431 Request Header Fields Too Large gilt sowohl für eine übergroße Summe als auch für ein einzelnes übergroßes Feld. Im zweiten Fall sollte die Antwort das betreffende Feld nennen. Eine verkleinerte Anfrage darf erneut gestellt werden. Die 431-Antwort darf nicht im Cache landen und später auf eine andere Anfrage mit anderen Feldern angewendet werden.

Eine Diagnose ist damit möglich, eine automatische Reparatur noch nicht. Die Norm legt keine einheitliche Bytezahl fest und wählt kein Cookie zum Löschen aus. Unter Angriff kann ein Server sogar die Verbindung schließen, statt 431 zu senden. Ein Besucher sieht dann nur eine gescheiterte Seite. Der Ursprung der Ablehnung kann im Gateway liegen, bevor der Anwendungscode überhaupt eine Anfrage erhält. Welche Komponente die Grenze gezogen hat, zeigen erst ihre Protokolle und eine Aufnahme der betreffenden Anfrage.

Sämtliche Cookies zu löschen kann die Anfrage verkleinern. Es beendet womöglich auch die Sitzung und verwirft Einstellungen. Wenn dieselbe Anwendung dieselben Werte wieder setzt, kommt der Stau zurück. Eine Hilfeseite, die nur mit dem identischen großen Header erreichbar ist, liegt hinter derselben verschlossenen Tür. Der Betreiber kann stattdessen Umfang, Geltungsbereich und Lebensdauer der ausgegebenen Werte ändern und einen leichten Wiederherstellungsweg offenhalten.

Kompression ändert die Eingangskontrolle nicht

Die späteren Protokolle behielten die Annahmeentscheidung bei. RFC 9113 von 2022 erlaubt einem HTTP/2-Server, auf einen zu großen Feldblock mit 431 zu antworten. RFC 9114 beschreibt dasselbe für einen HTTP/3-Header-Abschnitt. Kompression macht die Übertragung günstiger. Die empfangende Komponente muss die Felder weiterhin verarbeiten und kann ihr eigenes Budget setzen.

Im Störungsfall können deshalb beide Teams recht haben: Die Netzwerkmessung meldet wenig übertragene Bytes, das Gateway zu viele interpretierte Header-Felder. Auch ein riesiges Cookie muss von vielen gewöhnlichen Feldern in Summe unterschieden werden. Autorisierungsfelder verbrauchen ebenfalls Platz. Die vier RFCs enthalten keine Zahl realer 431-Ausfälle durch Cookies. Der konkrete Fall wird durch den Request am ersten Ablehnungspunkt und dessen Logs entschieden.

Der interessante historische Schritt liegt in der Arbeitsteilung. Der Browser trägt gehorsam zurück, was der Server bestellt hat. Die Infrastruktur achtet auf ihre Grenze. Die Anwendung wartet womöglich auf einen Request, der sie nie erreicht. Aus Sicht der Kundin ist das ein einziger Shop. Die Statusnummer erklärt ihr Problem erst dann, wenn der Betreiber seine eigene Ausgabe und seinen Eingang gemeinsam betrachtet.