Zusammenfassung

  • RFC 2109 standardisierte Set-Cookie und Cookie, um getrennte HTTP-Austausche in einer logischen Sitzung zu verbinden, unabhängig von einer dauerhaften Netzwerkverbindung.
  • Domain, Path, Max-Age, Secure und Cache-Regeln begrenzten den Zustand; zugleich verlangte der Text Nutzerkontrolle und Einschränkungen für automatisch eingebettete oder umgeleitete Anfragen.
  • Ein zurückgesandter Wert belegte Zustandsauswahl durch den User Agent, nicht die anwesende Person, informierte Einwilligung, Berechtigung, Aktualität, Transaktionsabsicht oder Wirkung.

Eine logische Sitzung war keine Leitung

RFC 2109 stellte ausdrücklich klar, dass „Sitzung“ keine persistente Netzwerkverbindung meint. Verbindungen durften enden oder wiederverwendet werden, ohne die Cookie-Sitzung zu definieren. Der Origin begann mit Set-Cookie, der User Agent konnte mit Cookie fortsetzen, beide Seiten konnten beenden, und Max-Age=0 forderte Löschung.

Damit blieben drei Zustände getrennt: eine offene Verbindung, ein gespeicherter Browserwert und eine vom Server noch akzeptierte Sitzung. Keiner beweist den anderen. Eine lebende TCP-Verbindung kann eine widerrufene Sitzung tragen; ein gespeicherter Wert kann mehrere Verbindungen überdauern.

Das Warenkorb-Beispiel erzählte mehr als der Header

Customer, Part_Number und Shipping wurden nacheinander gesetzt und bei passenden Pfaden zurückgegeben. Der Drahtbeleg zeigt Ausgabe, Speicherung und Auswahl. Er zeigt nicht, dass die aktuelle Person der benannte Kunde ist, den Kauf jetzt will, noch berechtigt ist oder dass die letzte Antwort Zahlung und Lieferung vollendet hat.

Der Wert war für den User Agent opak und konnte dennoch im Header lesbar sein. Domain folgte den historischen Abgleichsregeln, Path wählte URI-Präfixe, Max-Age eine gewünschte Lebenszeit, Version=1 die Verfahrensversion. Gleiche Namen konnten unter mehreren passenden Paths gemeinsam auftreten. Diese Regeln bestimmten Weitergabe, nicht Vertraulichkeit oder Entscheidungsgewalt.

Secure blieb ein Rat

Secure wies auf ein sicheres Mittel hin; der User Agent konnte bestimmen, welches Sicherheitsniveau er dafür hielt. Das Attribut verschlüsselte nicht selbst, authentisierte keine Person und band keinen Auftrag an eine aktuelle Vollmacht. Die Sicherheitsbetrachtung warnte gesondert vor Lesen und Verändern ungeschützter Header.

Ob der Wert Klartext, Datenbankschlüssel oder kodierter Zustand war, änderte die Verantwortlichkeit nicht: Der Server musste die Bedeutung und Gültigkeit bei Empfang prüfen.

Cache und Erinnerung brauchten getrennte Regeln

Die Trennung von Zustand, URL und Dokumentinhalt sollte die Skalierung durch Caches erhalten. Öffentliche Darstellungen konnten wiederverwendet werden; private Sitzungsinhalte gehörten nicht in gemeinsame Caches. Proxys sollten Felder weiterreichen und private, Gültigkeitsregeln sowie no-cache="set-cookie" beachten.

Eine gespeicherte Darstellung, ein ausgesandtes Set-Cookie, ein lokal angenommenes Cookie und eine später akzeptierte Sitzung sind deshalb vier Befunde. RFC 2068 lieferte die damalige HTTP/1.1-Cache-Semantik. HTTP/1.0-Caches konnten einzelne Header nicht allgemein ausnehmen und damit Zustandsfelder gefährlich mitkopieren.

Automatische Wiedergabe war schon ein Datenschutzproblem

RFC 2109 nannte eine Transaktion verifizierbar, wenn der Nutzer die URI vor ihrer Verwendung prüfen konnte. Automatisch geladene Einbettungen und Weiterleitungen waren typischerweise nicht verifizierbar. Die Regel sollte verhindern, dass eine Ursprungsaktion unbemerkt eine Sitzung mit einer fremden Domain startet oder fortsetzt; Ausnahmen sollten standardmäßig aus sein.

Das ist keine vollständige moderne Browserpolitik. Es benennt aber den Kern: Cookies sind nützlich, weil sie automatisch zurückkehren; gerade diese Automatik ist kein neuer menschlicher Entschluss.

Der Nutzer sollte Speichern und Senden abschalten, eine aktive Sitzung erkennen, Werte prüfen und Speicherung nach Domain steuern können. Die Spezifikation erkannte aufdringliches Tracking auch ohne sichtbare Identität und die spätere Verknüpfung durch identifizierende Formulare.

RFC 2964 betonte später informierte Einwilligung. RFC 2965 ersetzte RFC 2109 nach Implementierungserfahrung. RFC 6265 dokumentierte verbreitete Praxis, und der Autorenprüftext zu RFC 10025 gehört einer weiteren Generation an. Dokumentenfolge ist kein Nachweis für ein bestimmtes Produkt.

Ein Zustandsbeleg bleibt ein Zustandsbeleg

Eine belastbare Kette trennt: Server gab aus; User Agent nahm an; Nutzer behielt; Kontext wählte; Sitzung wurde akzeptiert; Richtlinie erlaubte; Aktion wurde verbucht; Wirkung wurde beobachtet. Das Cookie kann nur für einen Teil sprechen.

Lu Hengs Running-Code Primacy verlangt den Blick auf ausführbare Tatsachen. Minimum Initial Specification hält die gemeinsame Schicht klein. Reality Layers verhindert, dass ein Symbol die Autorität eines anderen Befunds übernimmt. RFC 2109 standardisierte Gedächtnis, nicht menschliches Mandat.

Quellen