Zusammenfassung

  • HTTPbis veröffentlichte am 9. September 2026 Revision 01 von draft-ietf-httpbis-pre-denied. Sie ist ein aktiver Arbeitsgruppenentwurf, weder RFC noch Beleg für eine IANA-Zuweisung von 419.
  • Aus „Preliminary Request Denied“ wird Purpose Declined; der Entwurf nennt 419 und erfasst Ablehnungen aufgrund des erklärten Sec-Purpose. Fetch definiert bislang nur prefetch.
  • Der Origin und ein in seinem Auftrag handelndes Gateway dürfen antworten. Ein unabhängiger Proxy sollte es nicht. Entscheidend ist das Recht, die Dienstpolitik zu vertreten, nicht die technische Fähigkeit, eine Antwort zu erzeugen.
  • Der Status verrät die angewandte Regel nicht. Ich schlage einen knappen Entscheidungsnachweis für Zweck, Akteur, Delegation, Richtlinienversion, Zeitpunkt, Cache-Behandlung und Ergebnis vor. Das ist Daniel Kades redaktioneller Vorschlag, keine Draft-Vorgabe.

Die Revision regelt eine Stimme, nicht nur eine Zahl

Am 9. September um 08:56 UTC stellte der Datatracker Revision 01 von The Purpose Declined HTTP Status Code bereit. Die vorherige Fassung beließ es bei einem allgemeinen 4xx und zielte mit „Preliminary Request Denied“ vor allem auf Prefetch und Preload. Nun steht 419 im Text, und die Semantik umfasst jede Anfrage, die wegen ihres erklärten Zwecks abgelehnt wird.

Der Verfahrensstand verlangt Genauigkeit. Es handelt sich um ein aktives Dokument der HTTPbis-Arbeitsgruppe im IETF-Stream, mit angestrebtem Status Proposed Standard und Tommy Pauly als Document Shepherd. Beim IESG steht weiterhin I-D Exists; weder verantwortlicher Area Director noch Bearbeitung oder Telechat sind verzeichnet. Im aktuellen IANA-Register bleibt 419-420 unassigned. Die Zahl ist also ein Arbeitsvorschlag.

Die institutionell wichtigere Änderung benennt die antwortenden Akteure. Ein Origin-Server darf 419 erzeugen. Dasselbe gilt für ein Gateway wie CDN oder Reverse Proxy, wenn es im Auftrag des Origins handelt. Ein unabhängiger Proxy sollte den Code nicht erzeugen.

Damit wird nicht behauptet, der Transit könne technisch keinen 4xx bauen. Beschränkt wird sein semantisches Mandat: Er darf eine eigene Präferenz nicht als Zweckrichtlinie des Origins ausgeben. Nähe in der Topologie schafft noch keine Delegation.

Ein erklärter Zweck ist keine geprüfte Absicht

Der Fetch Standard weist Sec-Purpose eine schmale Aufgabe zu. Der strukturierte Header zeigt an, dass eine Anfrage einem anderen Zweck als der unmittelbaren Nutzung dient. Zum Berichtszeitpunkt ist prefetch der einzige definierte Token. Server können daraufhin etwa die Cache-Laufzeit ändern, den Vorabruf ablehnen oder den Besuch anders zählen.

Der breitere Name „Purpose Declined“ hält Raum für künftige Token frei. Er definiert sie nicht. Auch erhält der Server keine neue Fähigkeit: Ablehnen konnte er schon vorher. Der Entwurf macht lediglich die Kategorie des bestehenden Verhaltens für Client und Betrieb lesbarer.

Lesbarkeit darf nicht mit Beweis verwechselt werden. Sec-Purpose: prefetch hält die Aussage des Clients über diese Anfrage fest. Daraus folgen weder der subjektive Wille des Nutzers noch Zustimmung zu Hintergrundverkehr, der auslösende Softwarebaustein oder die Richtigkeit der Deklaration. Umgekehrt erklärt 419 nicht, ob eine pauschale Sperre, Last, Kosten, Region, Missbrauchssignal oder Ausnahmeprüfung ausschlaggebend war.

Das Protokoll trägt zwei begrenzte Aussagen: Der Client deklarierte einen Zweck, und ein befugter serverseitiger Akteur lehnte darauf gestützt ab. Für ein allgemeines Urteil über die Legitimität der Anfrage reicht das nicht.

Ein Gateway-Mandat muss prüfbar bleiben

An der Edge fallen Richtlinieneigentum und Entscheidungspunkt oft auseinander. Ein CDN beendet die Verbindung, bevor die Anwendung die Anfrage sieht. Ein Reverse Proxy führt Regeln für mehrere Dienste aus. Das spart Ressourcen, erschwert aber die spätere Zuordnung.

Aus der Statuszeile geht nicht hervor, ob die Anwendung selbst entschied, ein Gateway eine ausdrücklich delegierte Regel vollzog oder ein administrativ unabhängiger Vermittler eingriff. Unbekannt bleiben auch Origin oder Tenant, Richtlinienversion und geprüfte Ausnahmen.

Die Lösung besteht nicht darin, private Regeln in eine öffentliche HTTP-Antwort zu schreiben. Der Security-Abschnitt des Drafts weist darauf hin, dass eine zweckbezogene Ablehnung internen Serverzustand offenlegen kann. Sinnvoller ist ein kontrollierter Minimalnachweis: exakter Sec-Purpose-Token; entscheidende Komponente und Rolle; vertretener Origin oder Tenant; stabile Richtlinienkennung samt Version; Entscheidungszeit; Ergebnis; versandte Cache-Behandlung; und, soweit sicher, eine Grundklasse.

Der Nachweis ist weder Vollprotokoll noch Nutzerprofil. Er soll eine strittige Entscheidung reproduzierbar machen und zeigen, dass das Gateway innerhalb seines Auftrags handelte. Physische oder logische Nähe zum Origin genügt dafür nicht.

Das Cache-Verbot begrenzt die Reichweite der Entscheidung

Revision 01 verlangt einen Inhalt der Länge null und empfiehlt, dennoch empfangenen Inhalt zu verwerfen. Außerdem ist 419 nicht heuristisch cachefähig und sollte nicht gespeichert werden. Dadurch wird eine kontextabhängige Ablehnung nicht versehentlich zu einer dauerhaften Regel.

RFC 9110 hält die Rückfallsemantik bereit: Ein Client ohne Kenntnis von 419 behandelt ihn wie das x00-Element der Klasse, also als allgemeinen 4xx-Fehler. RFC 9111 regelt das Caching insgesamt. Die schärfere Anweisung des Drafts verhindert, dass eine Entscheidung unter bestimmter Last oder Richtlinienversion nach einer Änderung weiter abgespielt wird.

Bei einem geteilten Gateway kann eine gespeicherte Ablehnung Tenant-Grenzen überschreiten, eine Korrektur überleben oder eine Anfrage mit anderem Kontext treffen. Sie sieht dann wie eine neue Origin-Entscheidung aus, obwohl der Origin nichts neu bewertet hat. Cache-Behandlung gehört deshalb in denselben Nachweis wie Akteur, Mandat und Version.

Die Aufgabenteilung bleibt klar: minimale gemeinsame Semantik auf dem Draht, kontrollierte Verantwortungsdaten im Betrieb und eine lokale Offenlegungsentscheidung für ungefährliche Erklärungen.

Quellen