Zusammenfassung

  • RFC 9745 lässt eine Ressource mitteilen, wann sie abgekündigt wird oder wurde; RFC 8594 lässt sie anzeigen, wann ihre URI voraussichtlich nicht mehr reagiert. Beide Angaben sind standardmäßig ressourcenbezogene Hinweise und kein Nachweis einer Client-Migration.
  • Ein Client-Umstiegsbeleg sollte die beobachteten Header mit dem autorisierten Umfang, dem Nachfolger, den Nutzungsverantwortlichen, Messgrenzen, Kompatibilitätstests, Ausnahmen, Rückkehrbedingungen und dem Ergebnis nach der Abschaltung verbinden.

Analyse

Eine schwierige Ablösung beginnt oft mit einer völlig unauffälligen Antwort. Der Client sendet denselben Aufruf und erhält weiterhin 200 OK. Neu ist lediglich ein Deprecation-Header mit einem künftigen Datum. Auf der Serverseite wurde der Hinweis veröffentlicht. Auf der Verbraucherseite kann eine Bibliothek unbekannte Header verwerfen, während das Monitoring ausschließlich Fehlerquoten betrachtet.

RFC 9745 schafft für diesen Hinweis eine gemeinsame Form. Deprecation enthält ein Datum als Structured Field. Liegt es in der Zukunft, bezeichnet es den vorgesehenen Beginn der Abkündigung. Liegt es in der Vergangenheit, bezeichnet es den bereits eingetretenen Zeitpunkt. Die Erklärung der Abkündigung verändert das Verhalten der Ressource nicht. Sie kann nach dem Datum unverändert funktionieren, obwohl der Verbraucher nicht mehr unterstellen darf, dass dies so bleibt.

Mit der Link-Relation deprecation kann der Anbieter zusätzliche Informationen auffindbar machen. Dort können Richtlinie, Zeitplan, Ersatz und Migrationshinweise stehen. Die IANA-Registrierung vereinheitlicht die Bedeutung der Relation, beglaubigt aber nicht die Vollständigkeit oder Aktualität eines konkreten Dokuments. Auffindbarkeit ist noch keine Umstiegsfreigabe.

RFC 8594 behandelt mit Sunset eine spätere Lebenszyklusfrage: Wann wird die URI voraussichtlich nicht mehr reagieren? Auch dieses Datum ist ein Hinweis. Es garantiert weder die Verfügbarkeit bis zu diesem Zeitpunkt noch die Nichtverfügbarkeit danach. Ob anschließend ein Fehler, eine Weiterleitung oder gar keine Verbindung folgt, bleibt offen. Wenn beide Felder gemeinsam auftreten, darf Sunset laut RFC 9745 nicht vor Deprecation liegen. Die richtige Reihenfolge beseitigt einen Konfigurationswiderspruch; sie belegt keine Bereitschaft der Clients.

Der Geltungsbereich bleibt zunächst klein

Beide Header beziehen sich im Normalfall auf die Ressource, die sie zurückgibt. Ein Anbieter darf festlegen, dass ein Hinweis auf der Startressource für eine ganze Version gilt. Wer diese besondere Regel nicht kennt, kann den erweiterten Umfang jedoch nicht erkennen. Ein Client, der nur einen tiefen Pfad aufruft, sieht den Hinweis auf der Startressource womöglich nie.

Ein gesammelter Header beweist deshalb nur, dass eine bestimmte URI zu einer bestimmten Zeit einen bestimmten Wert geliefert hat. Er beweist nicht, dass sämtliche Methoden, Regionen, Konten und Integrationen gemeinsam ausscheiden. Umgekehrt belegt das Fehlen des Feldes auf einem Pfad nicht, dass dieser Pfad von einer anderswo angekündigten Entscheidung ausgenommen ist.

Die RFCs behandeln Lebenszyklusangaben ausdrücklich als optionale Hinweise; Clients müssen auch ohne sie sinnvoll funktionieren. Eine Header-Erfassung ersetzt daher weder ein Abhängigkeitsverzeichnis noch die Ansprache der Verantwortlichen. Im Beleg gehören exakte URI, Beobachtungszeit, Antwortfingerabdruck und die ausdrückliche Regel zusammen, mit der eine befugte Stelle den Umfang erweitert hat.

Ein Link ist kein Befehl zur automatischen Umschaltung

Selbst ein korrektes Migrationsdokument rechtfertigt nicht ohne Prüfung die Umleitung produktiver Aufrufe. RFC 8594 warnt, dass maschinenlesbare Migrationsregeln eine weitreichende Änderung von Ressourcenidentitäten bewirken können. Verbraucher sollen Echtheit, Richtigkeit und Geltungsbereich prüfen, damit eine Richtlinie keine fremden Ressourcen vereinnahmt.

Der Nachfolger kann mehr ändern als den Hostnamen. Identitätsanbieter, Token-Audience, Berechtigungen, Quoten, Fehlerbedeutung oder Datenstandort können abweichen. Ein für den Server optionales Feld kann für die Geschäftsentscheidung des Clients wesentlich sein. Eine Weiterleitung, die einen Lesezugriff erhält, kann eine signierte Schreibanforderung ungültig machen. Geänderte Wiederholungsregeln können dieselbe Aktion zweimal auslösen.

Diese lokalen Tatsachen kann und soll ein Protokollfeld nicht zertifizieren. Der Standard transportiert die Lebenszyklusabsicht; die Beteiligten müssen die konkrete Umstellung prüfen.

Aufbau eines Client-Umstiegsbelegs

Der erste Teil hält die Meldung fest: kanonische URI, Beobachtungszeit, Antwortfingerabdruck, Deprecation- und gegebenenfalls Sunset-Wert sowie die damaligen Links. Er nennt den erklärten Umfang und die Instanz, die ihn über die einzelne Ressource hinaus festlegen darf. Widersprüchliche Aussagen bleiben als Widerspruch stehen.

Der zweite Teil beschreibt den Nachfolger. Neben Ziel-URI oder Version stehen Unterschiede bei Anfrage, Antwort, Authentisierung, Autorisierung, Audience, Quoten, Reihenfolge, Fehlern, Aufbewahrung und regionaler Verfügbarkeit. Die Dokumentation belegt die Ankündigung des Anbieters. Ein kontrollierter Versuch belegt das Verhalten einer bestimmten Client-Version unter bestimmten Bedingungen. Beides darf nicht zu einem pauschalen „kompatibel“ verschmelzen.

Der dritte Teil ist das Client-Verzeichnis. Jeder bekannte Verbraucher erhält einen Verantwortlichen, eine Kritikalität, die letzte beobachtete Nutzung, deren Messquelle, den Migrationsstand und den nächsten Entscheidungstermin. Keine gemessene Nutzung braucht einen Sichtbarkeitshinweis. Cache, Vermittler, Quartalslauf, Notfallumgebung oder getrennte Region können außerhalb der Telemetrie liegen.

Der vierte Teil regelt Ausnahmen. Dem Nachfolger kann eine Funktion fehlen, ein neuer Datenort auf Freigabe warten oder ein Fremdanbieter seinen eigenen Veröffentlichungstermin vorgeben. Eine belastbare Ausnahme besitzt Entscheider, Grund, Übergangsschutz und Ablaufdatum. Der bloße Weiterbetrieb ist keine Begründung.

Erst der letzte Teil autorisiert die Umschaltung. Er nennt Pilot-Clients, Erfolgs- und Abbruchkriterien, Rückkehrziel, Auslöser und den letzten sicheren Rückkehrzeitpunkt. Nach dem Termin wird das tatsächliche Verhalten der alten Ressource festgehalten. Eine Verschiebung löscht die frühere Zusage nicht; eine vorzeitige Abschaltung wird nicht durch den ursprünglichen Hinweis gerechtfertigt.

Mehrere Uhren statt eines Countdowns

Deprecation datiert die Bewertung des Ressourcenstatus. Sunset beschreibt eine Erwartung der Erreichbarkeit. Jeder Client hat ein eigenes Ziel, jede Ausnahme ein Ablaufdatum, jede Rückkehrmöglichkeit eine technische Grenze. Der wirkliche Abschaltzeitpunkt ist erst nach dem Ereignis beobachtbar.

Ein einziger Countdown verwischt diese Entscheidungsrechte. Er kann zu früher Abschaltung führen, weil „das Datum erreicht ist“, oder zu endlosem Aufschub, weil „es noch funktioniert“. Besser ist, jede Uhr mit Änderungsbefugnis, Beleg und Folge getrennt zu führen.

Quellen

  1. RFC 9745 — The Deprecation HTTP Response Header Field
  2. RFC 8594 — The Sunset HTTP Header Field
  3. IANA-Register der Link-Relationen