Zusammenfassung

  • draft-ietf-httpbis-pre-denied-01 schlägt 419 vor, wenn der Server die zugehörige Anfrage aufgrund ihres in Sec-Purpose erklärten Zwecks ablehnt; dieselbe Zweckangabe kann bei einer späteren Anfrage Erfolg oder Misserfolg haben.
  • Das Ereignis darf weder als dauerhafte Ressourceneigenschaft noch als Ausfall gespeichert werden. Es benötigt Zeit, Entscheidungspunkt, Cachepfad und ein getrenntes Ergebnis der nächsten Anfrage.

Um 10:00 Uhr wurde ein Prefetch abgelehnt. Um 10:01 Uhr gelang ein Prefetch auf dieselbe Zieladresse. Das Kontrollsystem markierte die zweite Antwort als Anomalie, weil es die erste als dauerhafte Sperre gespeichert hatte.

Tatsächlich war die erste Antwort die begrenzte Aussage und die gespeicherte Sperre die Anomalie. Zwischen beiden Versuchen konnten Last, Cachezustand, Darstellungskosten oder eine Edge-Regel wechseln. Der Entwurf verlangt keine stabile Entscheidung über die Zukunft.

Revision 01 von The Purpose Declined HTTP Status Code wurde am 9. September 2026 als aktiver Internet-Draft der IETF HTTP Working Group veröffentlicht und läuft am 13. März 2027 ab. Das Dokument ist für den Standards Track vorgesehen, bleibt aber veränderbare Arbeit. Zum Zeitpunkt der Quellenfixierung war 419 im IANA-Register der HTTP-Statuscodes nicht vergeben. Der Text ist weder RFC noch dauerhafte Zuteilung, Einsatznachweis oder Interoperabilitätsbericht.

Der Zeitbereich ist Teil der Semantik

Der Entwurf sagt ausdrücklich, dass die Anzeige nur für die zugehörige Anfrage gilt. Zukünftige Anfragen mit demselben Zweck können erfolgreich sein oder nicht. Diese Begrenzung ist keine Schwäche; sie verhindert, dass ein Ereignis stillschweigend zur Richtlinie wird.

Ein sicherer Datensatz lautet: Zu diesem Zeitpunkt hat dieser nachgewiesene Akteur diese Anfrage wegen ihres erklärten Zwecks abgelehnt. Er lautet nicht: Diese Ressource akzeptiert niemals Prefetch. Für eine dauerhafte Regel wäre eine authentisierte, versionierte Konfiguration nötig.

Automatisierung darf auf das Ereignis reagieren. Sie kann unmittelbare Wiederholung vermeiden, Zufall hinzufügen oder nach einer lokalen Wartezeit begrenzt prüfen. Sie darf den Zielort nicht unbegrenzt sperren und einen späteren Erfolg nicht als Vertragsbruch behandeln.

Zeitliche Überdehnung erzeugt Kosten in beide Richtungen. Eine ewige Sperre vernichtet mögliche Beschleunigung. Die Annahme dauerhafter Annahme sendet unnötige Arbeit. Die nächste Anfrage braucht ihren eigenen Bescheid.

Der erklärte Zweck ist Kontext, keine Identität

Der Fetch Standard erlaubt einem User Agent, mit Sec-Purpose den Anfragezweck zu erklären. Beim Prefetch kann der Browser eine Darstellung abrufen, bevor eine gewöhnliche Navigation stattfindet.

Dieser Wert authentisiert keinen Menschen. Er beweist weder Klick noch Zustimmung noch künftige Navigation. Eine Browserheuristik kann die Anfrage erzeugen, ohne dass die Person sie wahrnimmt.

Der Empfänger darf den Kontext für seine Ressourcenentscheidung nutzen. Er darf ihn nicht ohne weitere Belege zum Urteil über Missbrauch, Berechtigung oder Eigentum machen. Ebenso beweist ein angenommener Prefetch kein Geschäftsergebnis.

Syntaktische Gültigkeit erhöht nur die Lesbarkeit des Feldes. Sie beweist nicht die Ehrlichkeit des Senders, die Richtigkeit der Klassifizierung oder die innere Absicht einer Person. Identität und Autorisierung bleiben eigene Kontrollflächen.

Ein besserer Code fügt keine neue Ablehnungsmacht hinzu

Die motivierende Beobachtung ist, dass Zweckablehnungen häufig mit 503 oder anderen breiten Codes kommuniziert werden. RFC 9110 beschreibt 503 als vorübergehende Unfähigkeit durch Überlastung oder Wartung. Das kann bei Betreibern eine falsche Störungshypothese auslösen.

419 würde enger sagen, dass die Anfrage aufgrund ihres erklärten Zwecks abgelehnt wurde. Laut Entwurf entsteht dadurch keine neue Fähigkeit. Ursprung und bevollmächtigter Gateway konnten bereits ablehnen; die vorgeschlagene Nummer verbessert die Bezeichnung.

Eine Bezeichnung verleiht jedoch keine Zuständigkeit. Ein fremder Proxy kann nicht dadurch im Namen des Ursprungs handeln, dass er den passenden Code schreibt. Auch eine wohlgeformte Antwort beweist nicht, dass die Implementierung den wahren internen Grund mitteilt.

Das Ereignis braucht daher Methode, Ziel, Sec-Purpose, Zeitpunkt, Verbindung, Antwortknoten, Delegationsstatus, Richtlinienversion und Cacheinformationen. Ohne diese Felder wird eine präzise Nummer zu einer unpräzisen Behauptung.

Ursprung und delegierter Gateway sind verschiedene Zeugen

Der Entwurf erlaubt dem Ursprungsserver und Gateways, die für ihn handeln, einschließlich CDN und Reverse Proxy, die Antwort zu erzeugen. Andere Proxys sollten dies nicht tun.

Eine Edge-Entscheidung kann echte delegierte Kontrolle sein. Sie ist nicht bloß Netzwerkrauschen. Trotzdem beweist sie nicht, dass die Ursprungsanwendung die Anfrage sah, überlastet war oder auf allen Pfaden gleich entschieden hätte.

TLS-Endpunkt, Route, Via, Proxy-Status, Korrelationskennung und Aufzeichnungen beider Seiten helfen bei der Zuordnung. RFC 9209 beschreibt Diagnosen der Zwischenverarbeitung, macht den Proxy aber nicht zum Zeugen des internen Ursprungszustands.

Die Untersuchung muss den engsten belegten Akteur nennen. Fehlende Abstammung darf nicht mit dem Wort „Server“ verdeckt werden, weil dieses Wort Edge, Cache und Anwendung zu einer erfundenen Einheit verschmilzt.

Bessere Störungsdaten brauchen getrennte Nenner

Die Abgrenzung von 503 kann Verfügbarkeitsmessungen bereinigen. Aber weniger 503 bedeutet nicht automatisch mehr Kapazität. Ereignisse können lediglich korrekt umbenannt worden sein.

Mindestens drei Größen sind getrennt: Dienstverfügbarkeit, Anteil zweckmarkierter Ablehnungen und Ergebnis der späteren normalen Navigation. Werden alle Nicht-2xx als Ausfall gezählt, verschwindet der semantische Gewinn. Wird 419 ganz entfernt, kann eine aggressive Regel Nutzerlatenz verschlechtern, ohne sichtbar zu werden.

Ein gutes Berichtssystem verbindet die Ereignisse, ersetzt sie aber nicht gegenseitig. Der Prefetch-Bescheid erklärt die Ressourcenkontrolle. Die Navigationsantwort erklärt die spätere Anfrage. Nutzerbeobachtung erklärt das Ergebnis.

Die Führung sollte deshalb nicht „Fehler reduziert“ fragen, sondern: Wurde die Zuordnung genauer, blieb Kapazität stabil, und änderte sich das Ergebnis? So wird ein saubereres Register nicht zur kosmetischen Verfügbarkeitsreform.

Ein Cache darf die Zeitgrenze nicht entfernen

Der Entwurf erklärt den vorgeschlagenen Status für nicht heuristisch cachebar und empfiehlt, ihn nicht zu speichern. Wiederverwendung ließe eine Entscheidung über Anfrage A die nie bewertete Anfrage B regieren.

RFC 9111 liefert die allgemeinen Cache-Regeln. Cache-Status aus RFC 9211 kann zeigen, ob ein Cache weiterleitete, wiederverwendete oder revalidierte. Diese Diagnose beweist nicht den internen Ablehnungsgrund; umgekehrt beweist 419 nicht den Cacheweg.

Bei vielen gleichen Antworten muss ermittelt werden, ob viele neue Entscheidungen oder eine alte Wiederholung vorliegen. Alter, Direktiven, Cache-Schlüssel, Hop-Aufzeichnungen und Protokolle des Entscheiders bestimmen, was gezählt wird.

Eine einzelne Antwort, hundertmal ausgeliefert, ist hundert Zustellungen, aber nicht hundert politische Entscheidungen. Diese Unterscheidung gehört in jedes Audit.

Freier Antworttext ist kein versteckter Vertrag

Die Antwort ist nicht zur Anzeige bestimmt. Sie sollte einen Inhalt der Länge null haben; gesendeter Inhalt sollte verworfen werden. Eine allgemeine Fehlerseite kann Überlastung, fehlende Berechtigung oder Wartezeit nennen, obwohl nichts davon der Entscheidungsgrund war.

Wer diesen Text parst, baut eine private Schnittstelle ohne definierte Herkunft. Die Nummer trägt nur die enge Zweckablehnung. Zusätzliche Angaben brauchen ein eigenes Format und eine eigene Autorität.

Der Sicherheitsabschnitt warnt außerdem vor Offenlegung internen Zustands. Wenn die Ausgabe mit Cachewärme, Kapazität oder Experimenten schwankt, kann ein Beobachter Übergänge ableiten. Operative Lesbarkeit und externe Informationsabgabe müssen gemeinsam gestaltet werden.

Quellen und Grenzen

Das eingefrorene Paket enthält Revision 01, Datatracker-Status, Verlauf und Referenzen, die HTTP-WG-Seite, den Fetch Standard, RFCs zu Semantik, Cache und Diagnosen, BCP 14 und das IANA-Register. Es belegt Vorschlag und Dokumentstatus.

Es belegt keine Einführung, reale Störung, Anbieterhandlung oder künftige Veröffentlichung. Das Anfangsbeispiel ist ein analytisches Szenario ohne behauptete Produktionstatsache.

Quellen