Zusammenfassung

  • Ein aktiver HTTP-Arbeitsgruppenentwurf schlägt 419 Purpose Declined vor, wenn ein Server eine Anfrage wegen ihres erklärten Sec-Purpose ablehnt. Das ist ein Beleg für diese Anfrage, kein Dauerverbot, Gesundheitsurteil oder neues Ablehnungsrecht. Am 29. September 2026 führte IANA 419–420 weiterhin als nicht zugewiesen.
  • Zweck, autorisierter Entscheidungspunkt, Nicht-Cachebarkeit, Altclient-Verhalten, SLO-Grundgesamtheit und spätere echte Nachfrage müssen verbunden bleiben. Andernfalls wird 419 downstream zu „sonstiger 4xx“ und dieselbe Fehlinterpretation lebt fort.

Der Bereitschaftsdienst sah steigende Fehler, aber keinen kranken Ursprung. Die fraglichen Requests waren vorgezogen worden, bevor ein Nutzer die Ressource brauchte. Der Client hoffte auf künftige Latenzersparnis; der Server entschied, einen Teil dieser Spekulation nicht auszuführen.

Das ist ökonomisch plausibel. Bei einem Treffer gewinnt der Client Zeit. Bei einem Fehlschlag tragen Ursprung und CDN Rechen-, Daten- und Transferkosten ohne Nutzung. Eine Ablehnung optionaler Arbeit ist nicht dasselbe wie die Unfähigkeit, reale Nachfrage zu bedienen.

Mit 503 Service Unavailable verschwinden diese Unterschiede. RFC 9110 beschreibt 5xx als serverseitiges Scheitern an einer scheinbar gültigen Anfrage. Ein Alarm, der 503 als Kapazitäts- oder Abhängigkeitsproblem behandelt, ist vernünftig. Falsch ist, die bewusste Ablehnung einer Spekulation in denselben Zähler zu legen.

draft-ietf-httpbis-pre-denied-01 vom 9. September 2026 schlägt deshalb 419 Purpose Declined vor. Der Server verweigert diese Anfrage aufgrund ihres erklärten Zwecks. Es ist ein aktiver Internet-Draft der HTTP-Gruppe mit angestrebtem Standards-Track-Status, kein RFC. Beim Einfrieren der Quellen waren 419–420 im IANA-Register unassigned.

Der Entwurf schafft keine Befugnis. Er macht eine bestehende Entscheidung lesbar: fehlte die Fähigkeit, oder wurde optionale Arbeit lokal nicht zugelassen?

Eine Zweckangabe ist keine Bedarfszusage

Fetch definiert Sec-Purpose für Zwecke jenseits der unmittelbaren Nutzung. Der einzige definierte Token ist prefetch: Eine Ressource wird geholt, weil sie voraussichtlich bald benötigt wird. Bei einem entsprechenden Initiator setzt Fetch Sec-Purpose: prefetch.

Der Server kann die Cache-Laufzeit anpassen, den Prefetch untersagen oder ihn anders als einen Seitenbesuch zählen. Der Header beweist weder spätere Navigation noch Prognosequalität, Identität oder Nutzen. Er liefert Kontext.

Der Client erklärt; der Ursprung entscheidet. Ein CDN oder Reverse Proxy kann entscheiden, soweit er im Namen des Ursprungs handelt. Ein beliebiger Vermittler erhält durch seine Netzposition keine Zulassungshoheit.

So bleibt die gemeinsame Spezifikation dünn: Zweck und begrenztes Ergebnis werden interoperabel, Last-, Kosten- und Vertragsregeln bleiben lokal.

Falsche Semantik verbrennt echte Ressourcen

Wer zweckbezogene Ablehnung als 503 zählt, schickt SRE in die falsche Fehlerdomäne, belastet das Error Budget und verfälscht Kundenberichte. Im Extremfall wird Kapazität gekauft, um einen Graphen zu senken, der aus absichtlicher Kostenkontrolle entstand.

403 Forbidden ist ebenfalls zu groß. Es klingt nach allgemeinem Verbot, obwohl ein unmittelbarer Abruf Sekunden später erfolgreich sein kann. 419 sagt nur: Diese Anfrage wurde wegen ihres Zwecks abgelehnt.

Der präzisere Code beweist nicht, dass die Regel gut war. Eine zu breite oder manipulierte Ablehnung kann Nutzer schädigen. Klassifikation beschreibt eine gemeldete Entscheidung, sie zertifiziert sie nicht.

Die Ablehnung endet mit dem Request

419 gilt laut Entwurf nur für die zugehörige Anfrage. Eine spätere Anfrage mit demselben Zweck kann anders enden. Cache, Last und Policy ändern sich; ein unmittelbarer Nutzerabruf ist ohnehin eine andere Tatsache.

Darum ist 419 nicht heuristisch cachebar und sollte nicht gecacht werden. Eine Wiederverwendung würde die Entscheidung vom Ursprung und ihrem Zeitpunkt ablösen. Erhielte der echte Abruf eine alte Ablehnung, hätte eine Optimierung eine reale Störung erzeugt.

Die Antwort ist nicht zur Anzeige gedacht, sollte null Inhalt haben, und gesendeter Inhalt sollte verworfen werden. Operative Erklärung gehört in Request-Kontext, Policy-Version und Trace, nicht in eine neue Fehlerseite.

Tests müssen mehrere Vorabfragen unter geänderten Bedingungen und danach einen Direktabruf ausführen. Sie beweisen, dass kein Cache die Ablehnung wiederholt, der richtige Entscheider erreicht wird und leere Inhalte nicht sichtbar werden.

Wer 419 sendet, muss dafür autorisiert sein

Der Ursprung und in seinem Namen handelnde Gateways dürfen 419 erzeugen. Andere Proxies sollten es nicht. Sonst könnte ein fremder Vermittler die Anfrage beseitigen und die Entscheidung fälschlich dem Dienst zurechnen.

Der Beleg braucht Erzeugungsort, Delegation, Policy-Version, Regel und Eingaben. Sec-Purpose authentifiziert keinen Absender. Auch die Fähigkeit eines CDN zur Auslieferung ist keine pauschale Vollmacht für Zulassungssemantik.

Der Entwurf nennt zudem mögliche Leaks internen Zustands. Variiert 419 mit Last oder Schwellen, lässt sich die Policy sondieren. Granularität und Missbrauch müssen begrenzt werden; semantische Unschärfe ist keine Sicherheitslösung.

Alte Clients bewahren die Klasse, nicht die Begründung

RFC 9110 verlangt, einen unbekannten 4xx-Code allgemein wie 400 zu behandeln. Das verhindert eine Erfolgsmeldung, erhält aber nicht „Purpose Declined“. SDK, Loglager, Retry-Bibliothek und Dashboard können alles zu generischem Clientfehler reduzieren.

Running-Code Primacy verlangt deshalb End-to-End-Prüfung von Client, Edge, Ursprung, Cache, Trace, Metrik, Alarm, SLO und Bericht. Eine spätere Registrierung ändert diese Software nicht automatisch.

Drei Dimensionen müssen erhalten bleiben: spekulativer Zweck, Identität des Entscheiders, Ergebnis des späteren Direktabrufs. Viele 419 können eine neue Clientstrategie statt einen Ausfall anzeigen. Gleichzeitig darf 419 echte Direktfehler nicht verdecken. „419 ist immer harmlos“ wäre nur die nächste falsche Aggregation.

Code und spätere Wirklichkeit verbinden

Ein belastbarer Record enthält Request-ID, Methode, Ziel, Initiator, Sec-Purpose, Client-Build und Cachezustand; danach Entscheider, Delegation, Policy-Version, Regel und Zeit; dann Status, Cache-Control, Länge und Traceposition. Abschließend wird die spätere echte Nachfrage mit Erfolg, Latenz, Bytes, Ursprungsarbeit und sichtbarem Ergebnis verknüpft.

Ohne diese Verbindung gibt es keinen Beleg für Einsparung oder Schaden. Keine spätere Nutzung kann vermiedene Arbeit bedeuten, deren Umfang aber gemessen werden muss. Ein erfolgreicher Direktabruf belegt Verfügbarkeit, kann jedoch zusätzliche Latenz zeigen. Scheitert er, löscht der frühere 419 den Vorfall nicht. Erhält er einen gecachten 419, wurde der Scope verletzt.

Direktverfügbarkeit und Prefetch-Annahme brauchen getrennte SLOs. Ihre Korrelation mit Kosten und Nutzererlebnis ist wertvoll; ihre Vermischung nicht.

Die Primärquellen belegen Entwurf, Prozessstand, Fetch-Semantik, HTTP-Regeln und fehlende IANA-Zuweisung. Sie belegen keinen Browser, CDN, Rollout, Spareffekt, Adoption oder Interoperabilität. Dafür braucht es Implementierungen und Messungen.

Die Stärke des Vorschlags ist seine Begrenzung: eine bestehende Ablehnung benennen, auf einen Request beschränken, nicht cachen, keinen Nutzerinhalt erzeugen und den Emittenten abgrenzen. Erst die laufende Beweiskette kann zeigen, dass der Server gesund war.

Quellen