Zusammenfassung

  • marketplaceMCI musste 1994 Bestell-, Abrechnungs- und Versanddaten über mehrere Web-Anfragen hinweg behalten. MCI lehnte Netscapes ersten Vorschlag ab, den Zustand auf dem Server zu speichern, und verlangte eine Ablage auf dem Client.
  • Netscape machte daraus eine allgemeine Browserfunktion: Der Server konnte einen Zustandswert senden, den der Browser bei späteren passenden Anfragen zurückschickte. Der Wert allein wies nicht nach, wer den Browser bediente.
  • RFC 2109 versuchte 1997, einen Mechanismus zu ordnen, den Implementierungen und Kompatibilitätsbedarf bereits geprägt hatten. Die Regeln benannten Grenzen bei Nutzerkontrolle, Lesbarkeit und ungeschützter Übertragung.

Ein Warenkorb machte das Vergessen des Protokolls zum Produktproblem

Das übliche Anfrage-Antwort-Muster des Webs hatte eine praktische Lücke. Eine HTTP-Anfrage forderte eine Ressource an und erhielt eine Antwort. Die nächste Anfrage brachte den bisherigen Stand der Anwendung jedoch nicht von selbst mit. Ein Händler konnte ihn auf seinem Server speichern, musste dann aber Sitzungsdaten und die Einträge verwalten, die nach dem Verschwinden des Browsers zurückblieben.

MCI plante marketplaceMCI als Online-Einkaufsumgebung: mit einem Browser unter eigener Marke, einem Webserver, Händler-Servern für Bestellungen und deren Abwicklung sowie Back-End-Systemen für Support und Händlerkonten. Die Aufgabe war konkret. Bestell-, Abrechnungs- und Versandinformationen sollten über eine Folge von Anfragen zusammenhängend bleiben.

Die entscheidende Designwahl steht in einem späteren Gerichtsprotokoll, nicht in einer Erzählung vom einsamen Erfinder. Bei einem Treffen am 10. August 1994 lehnte MCI Netscapes ersten Vorschlag ab, den Zustand serverseitig zu halten. Die Information sollte auf dem Rechner des Kunden liegen. Das Gericht bezeichnet den allgemeinen Wunsch als unstreitig, hält aber Meinungsverschiedenheiten über technische Einzelheiten fest.

Damit wechselte der kurzfristige Speicherort der Anwendung. Der Browser sollte zwischen Kontakten mit dem Server ein kleines Zustandsobjekt behalten. Netscape-Programmierer Lou Montulli bekam die Aufgabe. Er erinnerte sich später an einen Auftrag im Sommer, eine Warenkorbmethode für das sitzungslose HTTP zu entwickeln, wusste aber nicht mehr, dass MCI der konkrete Kunde war. Marc Andreessen sagte aus, das MCI-Projekt habe schließlich zu Cookies geführt und Netscape habe daraus eine allgemein nutzbare Funktion gemacht. Die Aussagen verbinden Kundenbedarf und Produktentscheidung, klären aber nicht jedes Detail der Entwicklung.

Der Browser wurde zum Träger des Anwendungszustands

Die überlieferte Netscape-Spezifikation beschreibt den Ablauf knapp. Ein Server konnte einer HTTP-Antwort ein Zustandsobjekt beilegen. Der Browser speicherte es und schickte es bei späteren Anfragen zurück, deren URL in den Geltungsbereich des Cookies fiel. Die Serveranwendung wählte den Wert aus und legte seine Bedeutung fest. Der Browser bewahrte ihn auf und transportierte ihn zurück.

So konnten ein Warenkorbverweis, Registrierungsdaten oder eine Präferenz mehrere Anfragen überdauern. HTTP wurde dadurch nicht zu einem dauerhaften Verbindungskanal. Eine Seite musste auch nicht den persönlichen Warenkorb jedes Besuchers enthalten, was für Web-Caches wichtig war. Der Server verschwand ebenfalls nicht aus der Rechnung: Er konnte den zurückgesandten Wert als Schlüssel verwenden, um andernorts gespeicherte Einträge abzurufen.

Netscapes Dokument nannte sich vorläufige Spezifikation und warnte zur Vorsicht. Die frühen Regeln begrenzten Host oder Domain, Pfad, Ablaufzeit und sichere Übertragung. Sie beschrieben, unter welchen Bedingungen ein Browser den Zustand zurückgab. Sie bewiesen weder den Namen noch die Zustimmung oder fortdauernde Anwesenheit einer Person.

Laut Gerichtsprotokoll lag Cookie-Entwurfscode am 3. oder 4. Oktober 1994 im Netscape-Repository; am 6. und 13. Oktober folgten weitere Änderungen. Die Parteien stritten über den genauen Zeitpunkt der praktischen Umsetzung. Eine belastbare Chronologie lautet daher: Kundenanforderung und Design im Sommer, Code Anfang Oktober nach dem Gerichtsprotokoll und anschließend die Verallgemeinerung für Netscapes Browser. Einen einzigen, von allen anerkannten Erfindungstag gibt es nicht.

Der Standard folgte auf den Browserentwurf

Im Februar 1997 veröffentlichten David Kristol und Montulli RFC 2109, „HTTP State Management Mechanism“. Das Dokument beschrieb Set-Cookie-Antworten und Cookie-Anfragen und legte eine gemeinsame Grammatik vor. Ein eigener historischer Abschnitt behandelte ausdrücklich die Kompatibilität mit Netscapes ursprünglichem Vorschlag. Standardisierung bedeutete hier auch, bereits verbreiteten Code und dessen Verhalten einzubeziehen.

RFC 2109 legte die Grenzen des Mechanismus offen. Ein User Agent sollte Nutzer entscheiden lassen, ob Cookies gesendet und behalten werden. Die Header waren auf dem Transportweg ungeschützt: Vertrauliche Werte konnten offengelegt oder verändert werden. Für den Browser war der Wert undurchsichtig, aber nicht zwingend unlesbar. Im Login-Beispiel weist sich die Person zuerst über ein Formular aus. Anschließend sendet der Server ein Cookie, das diese Identität widerspiegelt. Das Cookie setzt den Anwendungszustand nach diesem Schritt fort; es prüft die Identität nicht selbstständig.

Die Unterscheidung zählt, weil ein gespeicherter Browserwert einem Dienst nützen kann, ohne zu belegen, wer ihn gerade besitzt. Behandelt eine Anwendung den Besitz als Berechtigung, entsteht eine sitzungsgebundene Inhaberfähigkeit. Wer den Wert erhält, kann ihn innerhalb seines Geltungsbereichs und seiner Laufzeit womöglich erneut verwenden. Die Sicherheit hängt davon ab, wie die Anwendung ihn ausstellt, schützt, ablaufen lässt und widerruft. Der einfache Cookie-Austausch entscheidet das nicht.

Die Geschichte des Cookies ist weniger geheimnisvoll, als sein Name klingt. Ein Einkaufsablauf zwang ein Produktteam zur Entscheidung, wo Kontinuität liegen sollte. Der Browser wurde zum Boten eines vom Server gewählten Zustands; ein Kundenbedarf wurde zur wiederverwendbaren Funktion; und ein späterer Standard hielt die Kompatibilität mit laufender Praxis fest. Webanwendungen konnten nun eine Transaktion über getrennte Anfragen hinweg wiedererkennen. Zum Zeugen menschlicher Identität hinter diesen Anfragen wurde der Browser dadurch nicht.

Quellen und Grenzen