Zusammenfassung

  • 201 Created belegt die Anlage einer Trigger-Ressource. Es belegt nicht die abgeschlossene Löschung, Invalidierung oder Vorpositionierung.
  • Hat ein Transit-CDN den Upstream-Auftrag schon angenommen, muss es eine spätere synchrone HTTP-Ablehnung seines Downstream-CDN in eine asynchrone Error.v2-Beschreibung der eigenen Ressource übersetzen.
  • Der PID des Fehlerursprungs ist optional. Status, Zähler, Abbruch, Knotenrückkehr und Nutzerwirkung benötigen getrennte Nachweise.

Die Arithmetik hinter dem grünen Haken

CDN A beauftragt B mit einem Purge. B prüft die Anfrage, legt eine Trigger-Ressource an und antwortet 201 Created. Danach gibt B den Auftrag an C weiter. C unterstützt einen Bestandteil nicht und sendet 400 Bad Request.

Beide Antworten sind korrekt. B bestätigt die Ressource bei B; C verweigert die Ressource bei C. Erst das Dashboard macht daraus einen Widerspruch, wenn es B's 201 als End-to-End-Erfolg zählt.

Revision 20 des CDNI Control Interface / Triggers 2nd Edition vom 2. September 2026 beschreibt diese Trennung ausführlich. Im IETF Datatracker ist sie ein aktiver CDNI-Arbeitsgruppenentwurf im Zustand „WG Document“. Bei Annahme würde sie RFC 8007 ablösen. Sie ist heute weder RFC noch IESG-Beschluss, Implementierungsbericht oder Beleg für einen realen Anbieter.

Gegenüber Revision 19 erweitert der Text insbesondere Fehlerbehandlung und Fehlerweitergabe. Nicht der Purge-Befehl ist neu, sondern die definierte Beweiskette nach einer vorgelagerten Annahme.

Aus einer Antwort wird ein späterer Eintrag

Erkennt B vor der Anlage ein falsches Format, fehlende Rechte oder eigene Nichtunterstützung, antwortet es mit 4xx und legt keine Ressource an. Nach B's Annahme ist der HTTP-Austausch mit A abgeschlossen. Ein späteres 4xx/5xx von C kann nicht rückwirkend zur damaligen Antwort an A werden.

B muss C's Ablehnung deshalb in eine Error.v2 Description umwandeln und im Fehlerfeld seiner eigenen Trigger-Ressource führen. Auch asynchrone Fehler von C werden so gemeldet. A erfährt sie durch späteres Polling als failed, etwa mit eunsupported.

Bei C war der Fehler eine direkte Antwort. Bei A ist er eine von B übermittelte Behauptung. Wer nur das 201 speichert, verliert das Scheitern. Wer nur den Endfehler speichert, verliert Reihenfolge und Übersetzungsstelle.

B darf C's CDN Provider ID beifügen, muss es aber nicht. Es kann den eigenen PID verwenden und C verschleiern. Die IANA-Register für CDNI-Parameter machen Codes gemeinsam verständlich; sie verpflichten Geschäftspartner nicht zur vollständigen Offenlegung.

Ein Endstatus hat einen Geltungsbereich

Der normale Verlauf führt von pending über active zu complete oder failed. Ein Transit-CDN darf complete erst melden, wenn der Auftrag bei ihm selbst und sämtlichen Downstream-CDNs vollständig ist. Meldet irgendein Beteiligter processed, muss das Transit-CDN ebenfalls processed melden.

Processed heißt: angenommen, aber ohne weitere Statusaktualisierung. Das ist eine Sichtbarkeitsgrenze, kein stilles complete. Ein nach RFC 9562 empfohlener eindeutiger UUID schützt die Identität der Ressource und verhindert URI-Wiederverwendung; Erfolg folgt daraus nicht.

Auch failed wird nicht zwingend beim ersten Fehler gemeldet. Das Transit-CDN wartet, bis alle lokale und downstream Verarbeitung beendet ist. Der Endzustand schließt den bekannten Arbeitsgraphen, nicht die erste Störungszeit und nicht die Korrektur beim Endnutzer.

Ein großer Zähler kann dieselbe Sache mehrfach zählen

Revision 20 ergänzt kumulative Zahlen für betroffene Objekte, Knoten und Bytes. Sie sollen über lokale Knoten und kaskadierte CDNs summiert werden, ohne dass dasselbe Objekt auf mehreren Knoten dedupliziert wird. Sie dienen der Erkennung unerwarteter Größenordnung.

Zehntausend bedeutet daher nicht zehntausend eindeutige Objekte. Null kann trotzdem Erfolg heißen, denn ein Purge ohne bekannte Treffer darf vollständig enden. Zählerdefinition, Duplikatregel, erwarteter Umfang und unabhängige Nutzerbeobachtung gehören zusammen.

Abbruch und Löschung haben eigene Rennen

Die tatsächliche Stornierung ist optional zu implementieren. Zwischen A's Beobachtung von pending und B's Bearbeitung kann der Trigger active werden. Active- oder processed-Arbeit kann vor dem Stopp fertiglaufen. Cancelling belegt einen laufenden Versuch, nicht das sofortige Ende aller Wirkung.

Eine Löschung entfernt die Status-Ressource und führt danach zu 404 Not Found. Deshalb empfiehlt der Entwurf den Abbruch, wenn der Upstream den Endstatus noch braucht. 204 No Content bestätigt die Entfernung des Datensatzes, nicht die Rücknahme der Cache-Aktion.

Auch der Datenzeitpunkt ist geteilt. Purge und invalidate müssen Daten erfassen, die vor active beschafft wurden, und sollten laufende Beschaffung erfassen. Später beschaffte Daten sollten ausgenommen sein, doch der Upstream soll sich nicht darauf verlassen, dass diese Trennung immer gelingt. Ohne Ablaufsteuerung kann ein unmittelbar vorpositionierter Ersatz vom früheren Purge getroffen werden.

Die Einordnung stammt aus RFC 6707 zum Interconnection-Problem, RFC 7336 zum Framework und RFC 7337 zu Control-Anforderungen. RFC 9110 definiert HTTP. Ein Erfolgscode bleibt trotzdem auf die von ihm beschriebene Operation begrenzt.

Der unsichtbare Knoten kommt zurück

Vorübergehende Nichtverfügbarkeit eines einzelnen dCDN-Knotens gilt als interne Betriebsbedingung und sollte allein den gemeldeten Trigger-Zustand nicht ändern. Vor normaler Rückkehr sollte der Knoten mit den während seiner Abwesenheit ausgeführten Triggern abgeglichen werden.

Die Abstraktion ist nützlich, überträgt aber Beweisverantwortung. Der Upstream-Endstatus war keine direkte Prüfung des abwesenden Knotens. Ein Nutzertest nach dessen Rückkehr prüft das eigenständige Risiko, dass alter Zustand wieder erscheint.

Diamond-Topologien können wegen unterschiedlicher Wege und Verzögerungen widersprüchliche Metadaten erzeugen und gelten als Konfigurationsfehler. PID-Pfade helfen gegen Schleifen, garantieren aber keine vollständige Lieferkettenansicht.

Das Protokoll verbessert den Statusbeleg. Es macht ihn nicht zum Beleg des gesamten Dienstes.