Zusammenfassung

  • RFC 10025 verlangt von Cookie-Erzeugern ein enges, wohlerzogenes Format und von Verbrauchern eine tolerantere Verarbeitung bestehender Serverausgaben. Auch eine korrekte Set-Cookie-Anweisung kann ignoriert, verworfen, normalisiert, ersetzt oder vorzeitig entfernt werden.
  • Gespeichert bedeutet nicht bei dieser Anforderung gesendet; gesendet bedeutet nicht durch die Anwendung berechtigt. Ein Lebenszyklusbeleg muss die getrennten Entscheidungen verbinden, ohne Cookie-Wert oder Sitzungsschlüssel zu protokollieren.

Nach einer fiktiven Anmeldung liefert der Dienst zwei getrennte Set-Cookie-Feldzeilen über TLS. Der Netzwerkmitschnitt bestätigt beide. Das Release-Dashboard meldet eine erzeugte Sitzung. Beim nächsten Aufruf fehlt der Bezeichner; ein anderer Aufruf enthält zwei gleichnamige Cookies.

Keine dieser Beobachtungen beweist einen Transportverlust. Der User Agent kann die neue Anweisung wegen einer Präfixbedingung verworfen oder aufgrund seiner Richtlinie ignoriert haben. Eine akzeptierte Zeile kann eine alte ersetzt haben, am Sitzungsende verschwunden, wegen einer Obergrenze verdrängt oder für die nächste Domain-, Pfad-, Sicherheits- oder SameSite-Situation ungeeignet gewesen sein.

RFC 10025, der im Juli 2026 als IETF Standards Track erschien und RFC 6265 ablöst, beschreibt genau diese Grenze. Set-Cookie übermittelt Name, Wert und Attribute. Eine spätere Cookie-Anforderung enthält ausgewählte Name-Wert-Paare. Sie quittiert weder die ursprüngliche Annahme noch den gespeicherten Kontext.

Unterschiedliche Pflichten sind Absicht

Cookie-erzeugende Implementierungen sollen das strengere Serverprofil verwenden. Cookie-verbrauchende Implementierungen müssen liberalere Regeln anwenden, weil vorhandene Server nicht immer diesem Profil folgen. Das ist eine Interoperabilitätsentscheidung. Sie erklärt, weshalb eine erfolgreiche Erzeugerprüfung kein identisches Ergebnis auf der Verbraucherseite garantiert.

Der Server kennt Zeichenfolge und Konfiguration. Er kennt nicht zwingend Engine, Richtlinienversion, Empfangskontext oder den durchlaufenen Zweig des Speicheralgorithmus. Dessen erster Schritt erlaubt dem User Agent sogar, ein empfangenes Cookie vollständig zu ignorieren. „Empfangen“ ist hier der Eingang in ein Verfahren, kein positives Urteil.

Die Verantwortlichkeiten liegen ebenfalls auseinander. Die Anwendung erzeugt die Anweisung, der HTTP-Stack transportiert die Feldzeilen, der User Agent parst und speichert, Nutzer oder Geräteverwaltung können Richtlinien setzen. Navigation, eingebettetes Dokument, Worker oder Nicht-HTTP-API schaffen später einen Abrufkontext. Erst danach entscheidet der empfangende Dienst über Sitzung und Zugriff.

Annahme übersetzt Text in lokalen Zustand

Verbotene Steuerzeichen, eine zu lange Kombination aus Name und Wert, eine unzulässige Domain oder verletzte Attribut- und Präfixbedingungen können die Speicherung abbrechen. SameSite=None verlangt Secure. __Secure- und __Host- erhalten ihre Zusagen nur mit den zugehörigen Bedingungen. Der User Agent prüft solche Präfixe ohne Beachtung der Großschreibung, damit eine unsaubere Serverauswertung keine falsche Sicherheitszusage erzeugt.

Die angenommene Zeile wird zu einem Datensatz mit Name, Wert, tatsächlichem Ablauf, Domain, Pfad, Erstellungs- und Letztzugriffszeit sowie persistent-, host-only-, secure-only-, http-only- und same-site-Zustand. Max-Age geht Expires vor. Ohne Domain entsteht Host-Bindung. Eine Ersetzung richtet sich nach Name, Domain und Pfad gemeinsam und übernimmt nach dem Algorithmus die frühere Erstellungszeit.

Der gesendete Text und die gespeicherte Zeile sind damit zwei Beweisobjekte. Eine datenschutzgerechte Diagnose hält einen Fingerabdruck der Anweisung, das Annahmeurteil, eine begrenzte Ablehnungsklasse und den normalisierten Geltungsbereich getrennt. Sonst erscheinen Syntaxfehler, Richtlinienentscheid, korrekte Ersetzung und Bereichsfehler als derselbe „fehlende Cookie“.

Ablauf ist Obergrenze, keine Verwahrzusage

Expires und Max-Age bestimmen den gewünschten Höchstzeitraum. Sie reservieren keinen Speicher. Der User Agent kann die Dauer begrenzen, abgelaufene Einträge entfernen und überzählige Cookies nach lokalen Domain- und Gesamtschranken verdrängen. Ein Nutzer kann löschen, eine Datenschutzrichtlinie kann früher aufräumen, und nicht persistente Zeilen verschwinden am Ende der lokal definierten Sitzung.

Die Aussage „bis nächstes Jahr gültig“ belegt daher keine Aufbewahrung bis nächstes Jahr. Dafür braucht es ein Ereignis: tatsächlicher Ablauf, Ersetzung, ausdrückliche Löschung, Sitzungsende, Kapazitätsdruck oder Richtlinienbereinigung. RFC 10025 empfiehlt Diensten gerade deshalb, mit ausbleibenden Cookies verträglich umzugehen.

In verwalteten Clients kann dieser Vorgang innerhalb der eigenen Betriebsgrenze detailliert nachvollzogen werden. Eine öffentliche Website sollte dagegen nicht den gesamten privaten Speicher verlangen. Grobe Grundklassen, Aggregation oder eine ausdrücklich erlaubte Diagnose sind ausreichend. Beobachtbarkeit rechtfertigt weder den Cookie-Wert noch fremde Browserverläufe im zentralen Log.

Jede Anforderung löst eine neue Auswahl aus

Ein vorhandener Datensatz muss zu URI, same-site-Status und Abrufart passen. Ablauf, Host oder Domain, Pfad, sicherer Kanal, HttpOnly und SameSite können ihn ausschließen. Der User Agent darf das Cookie-Feld unter seiner Richtlinie vollständig weglassen.

Der WHATWG Fetch Standard behandelt Cookies als Teil der Credentials einer Webanforderung. document.cookie aus HTML ist eine Nicht-HTTP-Schnittstelle und überschreitet HttpOnly nicht. Top-Level-Dokumente, Vorfahrendokumente, Reloads, Shared Worker und Service Worker erzeugen unterschiedliche Grundlagen für die Berechnung der „site for cookies“. Nur die Ziel-URL reicht zur Reproduktion nicht.

Auch SameSite ist kein Berechtigungsnachweis. Strict, Lax, None und Default wirken kontextabhängig. Für ein junges Default-Cookie kann der User Agent ein zeitlich enges Lax-allowing-unsafe-Verhalten anwenden. Der RFC beschreibt SameSite als zusätzliche Schutzschicht gegen bestimmte CSRF-Wege, nicht als vollständige Abwehr. Die Festlegung kommt zudem vom Server, nicht als Entscheidung des Nutzers.

Zurück kommt kein Speicherprotokoll

Im Anforderungsfeld stehen Name und Wert, nicht Domain, Path, SameSite, Erstellungszeit oder Auswahlgrund. Gleichnamige Einträge mit verschiedenen Pfaden oder Domains können gleichzeitig bestehen. Der Server soll aus ihrer Reihenfolge keine fachliche Priorität ableiten.

Bei HTTP/2 und HTTP/3 kann eine logische Cookie-Zeichenfolge über mehrere Feldzeilen transportiert werden. Das ist eine Darstellungseigenschaft, keine Herkunftsaussage.

Danach folgen Anwendungsentscheidungen: Parsergebnis, Sitzungssuche, Ablauf oder Widerruf, Authentisierung, CSRF-Schutz und Berechtigung für Methode und Ressource. RFC 9110 definiert HTTP-Semantik, aber keine örtliche Geschäftsvollmacht.

RFC 10025 nennt Cookies ambient authority. Ein Dritter kann eine Anforderung auslösen, woraufhin der User Agent ein ihm unbekanntes Geheimnis automatisch beifügt. Vorhandensein beweist deshalb keine Nutzerabsicht. Fehlen beweist ebenso wenig eine bewusste Ablehnung; es kann aus Geltungsbereich, Richtlinie, Ablauf oder Kapazität folgen.

Sechs Belege statt eines grünen Hakens

Die Ausgabe erfasst Antwort-URI, Zeitpunkt, geordnete und unverbundene Set-Cookie-Zeilen, Release- und Konfigurationsidentität sowie einen wertfreien Fingerabdruck. Die Annahme erfasst Verbrauchsengine, wirksame Richtlinie, Parsergebnis und Ablehnungsklasse. Der Speicherbeleg erfasst normalisierten Bereich, Flags, tatsächlichen Ablauf und Ersetzungsbezug.

Der Aufbewahrungsbeleg nennt Ablauf, Löschung, Sitzungsende oder Verdrängung, soweit legitim beobachtbar. Der Abrufbeleg bindet URI, Methode, Auslöser, obersten Kontext, SameSite-Berechnung und undurchsichtige IDs der aufgenommenen oder zurückgehaltenen Zeilen. Die Anwendung trennt Parse-, Sitzungs-, Authentisierungs-, CSRF-, Berechtigungs- und Ergebnisurteil.

Das ist Daniel Kades Governance-Vorschlag, keine von RFC 10025 vorgeschriebene Telemetrie. Cookie-Werte, Bearer-Token und Sitzungsschlüssel bleiben ausgeschlossen.

Damit wird Heng Lus Vorrang für laufenden Code als Primärbeleg praktisch. The Policy Mirror zeigt Entscheidung und Inhaber jeder Grenze, statt eine Serverabsicht als Clienttatsache auszugeben. So bleibt Realität statt Interessenvertretung das Produkt.

Quellen