Zusammenfassung

  • Nach draft-ietf-cdni-ci-triggers-rfc8007bis-20 muss ein nachgelagertes CDN auf einen Abbruchwunsch antworten; den wirklichen Abbruch zu implementieren ist jedoch optional. Selbst ein angenommener Wunsch kann gegen einen bereits startenden oder endenden Auftrag verlieren.
  • cancelling, cancelled, processed, complete und das Löschen einer Ressource sind verschiedene Belege. Löschen kann den Statuszugang beseitigen, obwohl die Inhaltsaktion noch zu Ende läuft.

Bei einem Cache-Vorfall werden zwei Sätze leicht verwechselt: „Der Abbruch wurde angenommen“ und „Der Purge ist nicht passiert.“ Dazwischen liegt die gesamte Ausführungskette eines CDN-Verbunds.

Revision 20 des Entwurfs CDNI Control Interface / Triggers lässt ein vorgelagertes CDN beim nachgelagerten Partner Inhalte oder Metadaten vorpositionieren, invalidieren oder purgen. Vorpositionieren holt sie vor dem Bedarf. Invalidieren verlangt eine erneute Validierung, ohne die gespeicherten Daten zwingend zu löschen. Purgen verlangt, dass die ausgewählten Daten nicht mehr gehalten werden. Schon die drei Aktionen haben unterschiedliche Nachweise und Folgen.

Auch der Abbruch läuft gegen die Uhr

Das nachgelagerte CDN muss den Abbruchwunsch beantworten. Die tatsächliche Abbruchfunktion bleibt laut Entwurf optional. Wird ein pending-Trigger beobachtet und sofort abgebrochen, kann er zwischen Beobachtung und Bearbeitung trotzdem starten. Ein active- oder processed-Trigger sollte nach angenommenem Abbruch stoppen, kann aber vorher noch regulär fertig werden.

Deshalb unterscheidet das Zustandsmodell sauber. cancelling belegt die angeforderte Unterbrechung. Erst wenn die Verarbeitung vor ihrem normalen Ende gestoppt wurde, gilt cancelled. Gewinnt die ursprüngliche Arbeit das Rennen, kann der Endzustand weiterhin complete oder failed lauten. Ein Steuerwunsch erzeugt keine rückwirkende Tatsache.

Auch der zeitliche Umfang eines Purges ist begrenzt. Daten, die vor active erworben wurden, müssen erfasst werden; laufende Abrufe sollten erfasst werden. Später erworbene Daten sollten nicht betroffen sein, doch der Entwurf warnt, dass dies nicht immer durchsetzbar ist. Der Trigger zieht also keinen perfekt synchronen Schnitt durch alle Cache-Prozesse.

Beim Versionswechsel wird das gefährlich. Beginnt die Vorpositionierung der neuen Fassung, bevor der alte Purge abgeschlossen ist, kann die neue Kopie eintreffen und unmittelbar danach vom älteren Auftrag entfernt werden. Eine Abhängigkeit in der Execution-Policy-Erweiterung kann die Reihenfolge erzwingen. Ohne sie erzeugen zwei korrekte Befehle möglicherweise das falsche Ergebnis.

Processed benennt eine Wissensgrenze

processed bedeutet im Entwurf: Der Trigger wurde angelegt, weitere Statusmeldungen folgen nicht, und sein Abschluss kann über diese Schnittstelle nicht bestätigt werden. Das Downstream-CDN arbeitet weiter und sollte, soweit möglich, eine Endzeit schätzen. Der Zustand ist weder verkappter Erfolg noch versteckter Fehler. Er markiert fehlende Abschlussbeobachtung.

Ein Betreiber darf den Vorgang deshalb nicht schließen. Beim Purge kann er den letzten Status, Objekt- und Fehlerangaben, veränderten Origin-Verkehr, Cache-Probes und die tatsächlich ausgelieferte Version zusammenführen. Bei Vorpositionierung lässt sich aus dem Ziel-Footprint prüfen, ob die erwartete Version bereitsteht. Die Beobachtungen sind nicht allwissend; sie verhindern aber, dass ein fehlender Beleg als positiver Beleg verbucht wird.

HTTP-Antworten liegen noch früher in der Kette. 201 Created bestätigt die Trigger-Ressource. 202 Accepted bestätigt Annahme ohne Abschluss. 204 No Content beim sofortigen Löschen bestätigt das Verschwinden der Statusressource. Keine dieser Antworten beschreibt allein den Inhalt jedes Caches.

Löschen kann den Zeugen entfernen

Der Entwurf stellt Löschen neben Abbrechen, nennt aber einen entscheidenden Unterschied: Nach dem Löschen ist die Trigger-Ressource nicht mehr verfügbar. Wer den späteren Zustand benötigt, soll daher abbrechen statt löschen.

Die Ausführungsrace bleibt beim Löschen bestehen. Ein pending-Trigger kann vorher starten; ein active- oder processed-Trigger muss nicht rechtzeitig stoppen. Damit können eine korrekte Löschantwort, ein verschwundener Status-URI und ein weiterlaufender Purge gleichzeitig wahr sein.

Automatische Ablaufzeiten schaffen dieselbe Beweislücke später. Das CDN darf terminale Ressourcen entfernen und danach 404 liefern. Es muss die Aufbewahrungszeit offenlegen und sollte processed nicht verfallen lassen, solange Ausführung oder Weitergabe plausibel noch läuft. Eine nie wiederverwendete UUID verhindert Identitätskollision; sie konserviert keinen bereits gelöschten Verlauf.

Eine Kaskade endet beim letzten Ast

Ein Transit-CDN kann den Trigger an weitere CDN weitergeben. Es darf complete erst melden, wenn die Aktion bei ihm und in sämtlichen betroffenen Downstreams abgeschlossen ist. Bleibt ein Ast processed, bleibt auch das Aggregat processed. Beim Abbruch bleibt cancelling bestehen, bis jeder Ast cancelled, complete oder failed erreicht hat.

Die Regel verhindert, dass der schnelle Ast für den langsamen spricht. Sie verlangt zugleich eine nachvollziehbare Zuordnung von Ursprungs-Trigger, Transitressourcen, CDN-Pfad, Astfehlern, Zustandszeitpunkten und späterer Inhaltsbeobachtung.

In einer Diamanttopologie kann dasselbe Downstream-CDN verwandte Daten über mehrere Wege und mit abweichenden Verzögerungen erhalten. Der Entwurf nennt dies einen Konfigurationsfehler. Erweiterte Zähler für Objekte, Knoten und Bytes können auffällige Größen zeigen, sind jedoch optional und deduplizieren dasselbe Objekt über mehrere Knoten nicht. Sie sind Plausibilitätsindikatoren, kein eindeutiges Objektbuch.

Complete ist stark, aber sachlich begrenzt

Der Entwurf verbietet complete, bis sämtliche im Trigger genannten Operationen erfolgreich abgeschlossen sind — einschließlich der Downstream-Kaskade. Das ist ein belastbarer Protokollbeleg.

Seine Aussage folgt trotzdem dem Auftrag. Ein Purge ohne Treffer darf mit null betroffenen Objekten erfolgreich enden. Das Auswahlmuster kann von der gedachten Menge abweichen. Und CDNI trennt Control, Metadata, Request Routing und Logging. Ein abgeschlossener Steuerauftrag beweist nicht automatisch, welche Repräsentation ein Endnutzer erhalten hat.

Ein belastbares Runbook hält daher fünf Stationen fest: Originaltrigger, Annahme beim Nachbarn, Abbruch- oder Löschwunsch, Terminalzustand jedes Kaskadenasts und unabhängige Beobachtung der Inhaltswirkung. Es erlaubt keinen irreversiblen Folgeschritt allein aufgrund von cancelling, processed oder einem 2xx und prüft die Partnerfähigkeiten vor dem Ernstfall.

Revision 20 bleibt ein Internet-Draft. Das eingefrorene IANA-Register enthält noch die RFC-8007-Typen statt der vorgeschlagenen .v2-Einträge; keine geprüfte Quelle belegt den Einsatz bei einem benannten CDN. Der Entwurf ist dennoch praktisch: Er lässt den Satz „Abbruch angenommen“ nicht mehr behaupten, als er beweisen kann.

Quellen