Summary

  • Der erste W3C-Entwurf zu Web Storage vom 23. April 2009 beschreibt zwei Flugbuchungen auf derselben Website. Ein Cookie für die „laufende“ Buchung kann Entscheidungen aus einem Fenster ins andere tragen.
  • sessionStorage ordnet Daten dem obersten Browserfenster und dem Ursprung zu; localStorage hält Werte für den Ursprung über Fenster und Sitzungen hinweg bereit. Beide geben Skripten Speicher im Browser, statt jeden Wert bei jeder HTTP-Anfrage mitzuschicken.

Wer einen Flug um sechs Uhr morgens bucht, braucht schon genug Überzeugungskraft. Noch unangenehmer wird es, wenn die Buchungsseite beim Bezahlen den anderen Flug hervorholt. Die Reisende hat zwei Fenster offen, prüft hier den Preis und dort das Gepäck. Die Website kennt aber nur eine Notiz mit der Aufschrift „aktueller Flug“. Bei jedem Wechsel wird sie neu beschrieben. Am Ende stimmt die Notiz; nur liegt sie am falschen Schalter.

Der erste Web-Storage-Arbeitsentwurf des W3C vom 23. April 2009 schildert diesen Fall mit zwei Flugtickets. Speichert die Seite den gerade gebuchten Flug in einem Cookie, können die Fenster ihre Auswahl gegenseitig überschreiben. Der Text nennt sogar den möglichen Kauf zweier Tickets für denselben Flug. Selten erklärt eine Spezifikation ihre Ausgangsfrage so anschaulich mit einer Kreditkartenabrechnung.

Ein Cookie reist mit passenden Anfragen zum Server. Dort hilft es, einen Browser wiederzuerkennen. Für zwei gleichzeitige Vorgänge auf derselben Seite liefert ein gemeinsames Feld „aktuell“ jedoch keine eindeutige Adresse. Der Browser weiß bereits, zu welchem obersten Fenster ein Dokument gehört. Web Storage machte diese Trennung für Skripte als Speicherort nutzbar.

Die erste Schublade heißt sessionStorage. Die W3C-Empfehlung von 2013 ordnet jedem obersten Browsing-Kontext eigene Speicherbereiche zu, jeweils getrennt nach Ursprung. Innerhalb eines Fensters kann die Buchung von der Flugauswahl über die Passagierdaten bis zur Bezahlung fortgesetzt werden. Das zweite Fenster führt seinen eigenen Vorgang. Wird ein neues Fenster aus einem vorhandenen geöffnet, kann es zunächst eine Kopie der Sitzungsdaten erhalten; danach entwickeln sich die beiden Kopien getrennt. Der Abendflug bleibt Abendflug, auch wenn nebenan gerade der Frühflug angeklickt wird.

Zum Fensternamen gehört der Ursprung. Er bestimmt, welcher Website der Bereich gehört. Eine andere Herkunft kann die Werte nicht einfach durchsehen. Die Adresse eines Buchungswerts lautet also sinngemäß: diese Website, dieses Fenster. Damit kann die Anwendung zwei Reisepläne nebeneinander führen, ohne jede neue Bildschirmseite wieder bei einer einzigen globalen „aktuellen Buchung“ abzuliefern.

Die zweite Schublade, localStorage, ist für einen längeren Aufenthalt gedacht. Ihre Schlüssel und Werte gehören einem Ursprung und sind in dessen Fenstern zugänglich, auch über eine Browsersitzung hinaus. Der Entwurf nennt selbst verfasste Dokumente und Postfachdaten als mögliche Inhalte. Als kleineres Beispiel zählt die Seite ihre Aufrufe. Ein Cookie wird mit jeder passenden Anfrage verschickt; ein lokal gespeicherter Zähler bleibt im Browser, bis ein Skript ihn liest und die Anwendung über eine Übertragung entscheidet. Für eine Zahl muss nicht ständig der ganze Aktenschrank auf Reisen gehen.

Die zweite W3C-Empfehlung von 2016 beschreibt auch die Handgriffe. setItem, getItem, removeItem und clear verwalten Einträge. Schlägt eine Änderung fehl, bleibt der vorherige Zustand erhalten. Bei vollem Speicher oder gesperrtem Zugriff kann setItem einen QuotaExceededError auslösen. Andere Dokumente, die denselben Bereich verwenden, erhalten nach einer Änderung ein storage-Ereignis. Skripte sollen konsistente Werte sehen; ein Aufruf muss dafür nicht jedes Mal auf eine physisch abgeschlossene Festplattenoperation warten.

Bei der praktischen Umsetzung wurde gestritten. Im Abschnitt „Issues“ der Empfehlung von 2013 steht, dass einigen Implementierern die vorgesehene Speichersperre gegen Wettläufe zwischen Fenstern zu teuer erschien. Die bequem gemeinsame Schublade brauchte Verkehrsregeln. Gerade weil die Schnittstelle so einfach aussah, wurde die Abstimmung zwischen gleichzeitig laufenden Skripten zu einer teuren Frage für den Browser.

Die Publikationsgeschichte des W3C führt vom Entwurf 2009 zu den Empfehlungen von 2013 und 2016. Das Bild der zwei Tickets blieb aussagekräftig. Eine laufende Buchung gehört zu ihrem Fenster. Ein aufbewahrter Entwurf gehört zum Ursprung. Ein Cookie begleitet die Anfrage an den Server. Wer jedem Wert die richtige Adresse gibt, erspart Reisenden eine unfreiwillige Zugabe auf der Rechnung.