Zusammenfassung

  • HTTP 431 trennt zu große Anfragefelder von zu großem Anfrageinhalt; HTTP legt jedoch keine gemeinsame Obergrenze für alle Implementierungen und Pfade fest.
  • Die Ablehnung kann die Gesamtheit oder ein einzelnes Feld betreffen. Verkleinern und erneut senden ist möglich, doch blindes Entfernen kann Berechtigung, Bedingung oder Ziel verändern.

Die Ablehnung vor dem Inhalt

Eine kleine Operation erreicht ein Gateway. Ihr Inhalt ist winzig oder fehlt, doch die Anfrage trägt ein langes Cookie, Zugangsdaten, Darstellungspräferenzen, Tracing und Weiterleitungskontext. Jedes Feld kann vernünftig sein; zusammen überschreiten sie das Budget eines Empfängers.

RFC 6585 gab diesem Zustand 2012 den Namen 431 Request Header Fields Too Large. Der Server will die Anfrage wegen ihrer großen Felder nicht verarbeiten. Nach einer Reduktion darf der Client sie erneut einreichen.

Das ist nicht der von RFC 9110 mit 413 bezeichnete Anfrageinhalt. Die Felder sind der Steuerumschlag für Interpretation, Autorität, Bedingungen und Weg. Eine Anfrage kann folglich zu groß sein, bevor ihr Body beginnt.

Gemeinsame Antwort, keine gemeinsame Grenze

RFC 9110 definiert keine vorgegebene Höchstlänge für eine Feldzeile, einen Feldwert oder den gesamten Feldabschnitt. Speicher und Analysezeit bleiben endlich, daher wählt jede Implementierung ihr eigenes Verarbeitungsbudget.

In einer Kette existieren mehrere Grenzen. Eine Clientbibliothek baut die Anfrage, ein lokaler Proxy akzeptiert sie, ein Edge-Gateway lehnt sie ab; ein anderer Pfad könnte einen Ursprung mit anderem Limit erreichen. Dieselben Bytes dürfen auf einem Weg funktionieren und auf einem anderen scheitern, weil es keine universelle HTTP-Zahl gibt.

431 gibt privaten Budgets eine gemeinsame Sprache. Der Code beweist allein weder, welcher Hop die kleinste Grenze setzte, noch, dass deren Erhöhung sicher wäre.

Einzelnes Feld und Gesamtheit sind verschiedene Befunde

RFC 6585 erlaubt 431 für einen insgesamt zu großen Feldsatz sowie für ein einzelnes verantwortliches Feld. Im zweiten Fall sollte die Antwortdarstellung dieses Feld nennen.

Ein isoliertes Feld lässt sich vielleicht verkürzen oder erneuern. Die Gesamtheit kann aus vielen unabhängigen Ergänzungen wachsen. Das größte Feld zu entfernen garantiert nicht, dass der nächste Hop den Rest akzeptiert. Der Name ist ein Hinweis, kein Ende-zu-Ende-Nachweis.

Auch Verantwortung ist verteilt. Cookies sammeln Zustand aus mehreren Antworten, Vermittler verlängern Weiterleitungsfelder, Rotation verändert Zugangsdaten und Tracing ergänzt Kontext außerhalb der Anwendung.

Stilles Ignorieren ändert die Anfrage

RFC 9110 verlangt einen passenden 4xx-Code, wenn Anfragefelder größer sind, als der Server verarbeiten will. Ignorieren erhöht die Gefahr unterschiedlicher Deutung und von Request Smuggling.

Felder tragen Anmeldedaten, Vorbedingungen, Zielauswahl und Interpretationsregeln. Ignoriert ein Hop, was ein anderer anwendet, bearbeiten beide nicht mehr dieselbe Anfrage. Abschneiden kann eine bedingte Änderung unbedingt machen, Berechtigung entfernen oder Nachrichtengrenzen spalten.

Der Server muss den gesamten Anfragefeldabschnitt empfangen, bevor er die Methode anwendet. Späte Felder können Bedingungen, Zugangsdaten oder irreführende Duplikate enthalten. Die sichere Verzweigung ist eine ausdrückliche Ablehnung und der Neuaufbau durch den Besitzer der Semantik.

Erneutes Senden ist Möglichkeit, nicht Zusage

Eine Reduktion erlaubt einen neuen Versuch, garantiert aber keinen Erfolg. Ein späterer Vermittler kann ein kleineres Limit haben, das entfernte Feld kann zwingend sein, die Operation kann veraltet sein. Bei Transportunsicherheit weiß der Client womöglich nicht, ob ein früherer Versuch wirkte.

Ein belastbarer Neuversuch wird aus maßgeblichem Zustand aufgebaut, bewahrt notwendige Anmeldedaten und Bedingungen, nutzt angebotene Idempotenz und prüft die fortbestehende Zweckmäßigkeit. Schnelles Wiederholen einer beschädigten Anfrage stellt ihre Bedeutung nicht wieder her.

Ein Cache darf das lokale Urteil nicht verlängern

RFC 6585 verbietet das Speichern von 431-Antworten. Das Urteil gehört zu einem Feldabschnitt, einem Pfad und einem aktuellen Empfangsbudget. Spätere Wiedergabe könnte eine verkleinerte Anfrage ablehnen oder die alte Einstellung eines Hops auf einen anderen Weg übertragen.

Ein Empfänger kann aus aktuellem Zustand ein neues 431 erzeugen. Ein Cache darf die Parsing-Entscheidung nicht als wiederverwendbaren Inhalt behandeln.

Unter Angriff kostet auch die Erklärung

Server müssen 431 nicht ausgeben. RFC 6585 erlaubt unter Angriff das Schließen von Verbindungen oder andere Schritte. Genug Daten für eine Diagnose zu lesen und zu analysieren verbraucht die geschützten Ressourcen; genaue Schwellen helfen möglicherweise beim Auskundschaften.

Bei vorhandener Kapazität unterstützt eine begrenzte Erklärung legitime Clients. Unter feindlichem Druck kann frühe Eindämmung Vorrang haben. Eine geschlossene Verbindung beweist öffentlich jedoch keine Feldüberschreitung; interne Beobachtung muss Ursachen unterscheiden.

Die schmale Wahrheit von 431

431 erklärt weder den Inhalt für zu groß noch eine Internet-Grenze für überschritten oder den Client für böswillig. Es sagt nur, dass ein Empfänger einen Steuerumschlag ablehnte, den er nicht verarbeiten wollte.

Diese Präzision machte ein verborgenes Limit reparierbar, ohne das Budget zu vereinheitlichen. Dauerhafte Disziplin heißt: Kontext begrenzen, verantworten und rekonstruierbar halten — und nie die Sicherheitsbedingung entfernen, nur damit der Umschlag passt.

Quellen