Zusammenfassung

  • RFC 2965 vom Oktober 2000 entwarf eine Versionsabsprache. Ein Client, der alte und neue Cookies beherrschte, sollte je nach Herkunft eines Werts weiter ein altes Cookie schicken und zusätzlich mit Cookie2: $Version="1" seine Fähigkeit anzeigen. Ein neuer Server sollte mit Set-Cookie2 fortfahren, ein alter durfte die Anzeige ignorieren.
  • Die neue Antwort konnte Port enthalten und so die Rückgabe eines Cookies auf bestimmte Ports beschränken. CommentURL bot eine Adresse für Erläuterungen an Nutzer. Die Fähigkeitsmeldung, die neue Serverantwort und eine Entscheidung des Nutzers waren verschiedene Schritte.
  • RFC 6265 vom April 2011 ersetzte RFC 2965, beantragte dessen historischen Status und verwarf Cookie2 und Set-Cookie2. Es beschrieb die tatsächlich verwendeten Felder Cookie und Set-Cookie und hielt fest, dass Cookies eines Hosts über dessen Ports hinweg geteilt werden.

Der Browser zeigt einen Ausweis vor

Eine Webseite möchte den Warenkorb über mehrere HTTP-Anfragen hinweg erkennen. Der Server legt einen Zustandswert beim Browser ab und erhält ihn bei passenden späteren Anfragen zurück. RFC 2109 vom Februar 1997 hatte eine frühe Form dieses Austauschs beschrieben. Wer ihn verbessern wollte, traf auf eine Welt aus bereits installierten Programmen. Kein zentraler Betreiber konnte alle Browser und Server am selben Tag umstellen.

RFC 2965 vom Oktober 2000 stellte darum eine höfliche Verhandlung auf. Für die neue Antwort des Servers gab es Set-Cookie2, für die Fähigkeitsanzeige des Clients Cookie2. Ein Browser, der beide Generationen verstand, sollte für einen über das ältere Set-Cookie erhaltenen Wert weiterhin das passende alte Cookie zurücksenden. Gleichzeitig sollte er Cookie2: $Version="1" hinzufügen. Er signalisierte damit: Diese Unterhaltung kann bei Bedarf in der neueren Sprache weitergehen.

Ein Server, der diese Sprache ebenfalls verstand, sollte die Sitzung mit Set-Cookie2 fortsetzen. Ein Server ohne neue Regeln durfte Cookie2 schlicht übersehen. Sein bisheriger Austausch blieb möglich. Die Migration setzte also keinen Zwangswechsel voraus, bevor ein einzelner Client eine neue Nachricht verschicken durfte.

Bei der Auswertung eines Mitschnitts muss man die Aufgaben auseinanderhalten. Cookie2 trug eine Aussage über die verstandene Version, keine Sammlung von Sitzungswerten. Set-Cookie2 war die Antwort mit dem neuen Cookie und seinen Attributen. Die später passenden Werte gelangten wiederum im Anfragefeld Cookie an den Server. Eine sichtbare Fähigkeitsmeldung ist der Anfang einer möglichen neuen Konversation; ob sie stattfand, steht in den folgenden Nachrichten.

Der Server blieb frei, den zurückgesandten Zustand für seine Anwendung zu nutzen oder nicht. RFC 2965 organisierte einen Austausch zwischen Geräten. Ein Header allein war weder ein Beleg für eine abgeschlossene Bestellung noch für das Verständnis eines Nutzers. Gerade diese Trennung macht den Migrationsentwurf verständlich: zuerst die Fähigkeit, dann die gewählte Antwort, danach der tatsächliche Gebrauch.

Wofür der neue Weg gut sein sollte

Das neue Feld hatte mehr zu bieten als eine Ziffer im Namen. Set-Cookie2 konnte ein Port-Attribut tragen. Ohne dieses Attribut durfte ein Cookie an jeden relevanten Port desselben Hosts zurückgehen. Stand Port ohne Wert da, war die Rückgabe auf den Port beschränkt, von dem der Cookie stammte. Eine Liste erlaubte nur die aufgeführten Ports. Für zwei Dienste auf derselben Maschine war das ein Ansatz, ihre Zustandswerte enger zu trennen.

CommentURL richtete sich an eine andere Grenze. Der Ursprungsserver sollte über die Nutzung eines Cookies informieren; die URL konnte ausführlichere und mehrsprachige Erläuterungen bieten als ein kurzer Kommentar im Header. Das war ein Versuch, die Entscheidung des Menschen in einer maschinengetriebenen Technik sichtbar zu machen. Die angegebene Seite bot eine Gelegenheit zum Lesen. Ob sie geöffnet und verstanden wurde, hing von späterem Verhalten ab.

Das Upgrade verband damit drei konkrete Versprechen: engeren Rückgabebereich, eine Informationsadresse und Erkennung der Gegenstelle. Jedes brauchte Teilnehmer, die es wirklich unterstützten. Ein Server mit Set-Cookie2 konnte einen alten Browser nicht zu neuer Interpretation zwingen; ein neuer Browser konnte einen alten Server nicht zu einer Antwort mit einem unbekannten Feld überreden.

Die Koexistenzregeln waren entsprechend ausführlich. Ältere Clients erkannten Set-Cookie2 nicht und nutzten ihre gewohnte Cookie-Welt. Ein Client mit beiden Regeln musste festhalten, auf welchem Weg ein Wert angekommen war, und die passenden Rückgabevorschriften anwenden. Erhielt er für einen gleichwertigen Cookie zugleich alte und neue Antwortfelder, sollte der neue Wert Vorrang haben. Kompatibilität schützte laufende Sitzungen, machte die Implementierung der verbesserten Seite aber zu einer Arbeit mit zwei Protokollwegen.

Die RFCs liefern keine Zahl der Browser, die Cookie2 sendeten, und keine Zahl der Server, die mit Set-Cookie2 antworteten. Datierte Softwareversionen und reale Kommunikationsspuren würden die Verbreitung klären. Der offizielle Text zeigt den beabsichtigten Ablauf und den späteren Beschluss, nicht jede einzelne Installation.

2011 wird die Ausweichspur zum Standard

RFC 6265 vom April 2011 setzte anders an. Es definierte Cookie und Set-Cookie anhand ihres tatsächlichen Gebrauchs im Internet. Die Einleitung stellt fest, dass ältere Beschreibungen, darunter RFC 2109 und RFC 2965, diesen Gebrauch nicht angemessen wiedergegeben hatten. Server sollten Cookies in einer disziplinierten Form ausgeben; Clients mussten zugleich die vielseitigen Antworten vorhandener Server verarbeiten können. Die Autoren schrieben Regeln für die Fahrzeuge, die schon auf der Straße waren.

Im selben Abschnitt verlangte das Dokument, RFC 2109 und RFC 2965 als historisch einzuordnen, ersetzte RFC 2965 und verwarf ausdrücklich Cookie2 und Set-Cookie2. Im Verzeichnis der Header stehen beide als veraltet. Die Fähigkeitskarte und der neue Ausgabeschacht verschwanden aus dem Kernvertrag. Die gewöhnlichen Felder blieben.

RFC 6265 erklärte die gewöhnlichen Felder damit nicht für tadellos. Es wies darauf hin, dass Cookies für denselben Host über verschiedene Ports geteilt werden, obwohl Browserinhalte unter der Same-Origin-Regel normalerweise anhand des Ports getrennt sind. Genau hier hatte das Port-Attribut von 2000 eine engere Rückgabe ausdrücken können. Das Standarddokument von 2011 stellte den gelebten Austausch dar, statt diese Versionsfunktion als zentrale Pflicht zurückzubringen.

Der Unterschied liegt deshalb nicht im Klang zweier Headernamen. 2000 hatte der Standard einen sanften Wechsel entworfen und den alten Weg offen gelassen. 2011 hatte der alte Weg eine installierte Bevölkerung aus Anwendungen und Programmen. Ein Herausgeber des RFC konnte einem Browser vorschreiben, wie die Fähigkeitskarte aussehen sollte; die Fähigkeit musste trotzdem in einer laufenden Anfrage auftauchen und auf einen Server treffen, der sie nutzte.

Die dokumentarische Entscheidung ist klar: RFC 2965 wurde abgelöst, beide Versionsfelder wurden aufgegeben. Für die Geschichte einzelner Browserversionen wären gesonderte Implementierungsaufzeichnungen nötig. Die Standardtexte selbst zeigen die Richtung: Im Jahr 2000 sollte Cookie2 eine neue Sprache eröffnen; elf Jahre später schrieb die nächste Norm die verbreitete alte Sprache auf.

Der Rückweg hatte genug Verkehr

Das Scheitern des neuen Pfades lässt sich nicht durch einen einzelnen kaputten Schalter erklären. Der Plan erlaubte ausdrücklich, dass ein alter Server Cookie2 ignorierte und ein alter Client Set-Cookie2 nicht verstand. Er hielt die vorhandene Welt am Laufen. Dadurch musste aber jede Verbesserung auf zwei aktualisierte Enden derselben Verbindung warten. Betreiber konnten auf die jeweils andere Seite zeigen und weitermachen wie bisher.

Die Kosten dieser Wahl stehen in den Quellen: Port und CommentURL blieben Teile des gestrichenen Entwurfs, während das neue Standarddokument die weite Portfreigabe des tatsächlichen Cookie-Gebrauchs beschrieb. Eine auf dem Papier bessere Grenze ist noch keine wirksame Grenze auf Millionen Geräten. Dafür braucht es eine Verteilung von Software, Tests und laufenden Sitzungen.

Kompatibilität ist ein mächtiges Geschenk. Sie kann einen Übergang ermöglichen und ihn zugleich auf Dauer vertagen. Cookie2 war das höfliche Klopfen an der Tür des Upgrades. 2011 archivierte HTTP die Visitenkarte und beschrieb die Tür, durch die der Betrieb bereits ging.