Zusammenfassung

  • AppCache sollte Webanwendungen ohne Netzverbindung verfügbar halten. Eine Seite verwies auf ein Cache-Manifest, der Browser speicherte die dort genannten Dateien. Ein neues Skript auf dem Server allein erneuerte die gespeicherte Fassung nicht; das Manifest selbst musste sich ändern.
  • Schlug das Laden des Manifests oder einer verlangten Datei fehl, konnte die ganze Aktualisierung scheitern und die alte Anwendung weiterlaufen. Chrome begann 2020 mit der Abschaltung von AppCache als Standard. Die kleine Dateiliste war zu einem Freigabeschalter geworden.

Der reparierte Code wartete vor der Tür

Ein Entwickler behebt einen Fehler in main.js und lädt die Datei hoch. Beim Leser läuft weiterhin die alte Version. Der Google-Leitfaden zu AppCache erklärte diese scheinbar absurde Szene: Die Änderung eines bereits zwischengespeicherten Skripts oder Bildes veranlasste den Browser nicht von allein zum erneuten Speichern. Dafür musste die Manifestdatei geändert werden. Schon eine neue Versionsmarke in einer Kommentarzeile konnte den Ausschlag geben.

Offline-Zugriff hatte damit einen Preis in der Veröffentlichungskette. Der Browser konnte eine vollständige Anwendung behalten, wenn die Verbindung ausfiel. Zugleich erhielt ein repariertes Einzelteil vom Server keinen direkten Weg in diese lokale Anwendung. Die Liste war Schutzplan und Release-Knopf in einem.

Ein geplanter Vorrat statt zufälliger Cache-Reste

Die W3C-Notiz vom Mai 2008 beschrieb den Ausgangspunkt: Mail, Kalender und andere Webprogramme sollten auch ohne Verbindung aufgehen. Ein allgemeiner HTTP-Cache garantiert nicht, dass dafür alle nötigen Teile vorhanden sind. Das manifest-Attribut des HTML-Wurzelelements verwies daher auf eine Datei vom Typ text/cache-manifest. Sie nannte die aufzubewahrenden Ressourcen. Ein Abschnitt NETWORK: bezeichnete Anfragen, die weiterhin über das Netz laufen sollten.

Diese Liste gab dem Autor eine klare Auswahl. Der Browser musste sie jedoch als zusammengehörige Anwendung behandeln. Laut Google-Leitfaden ließ ein fehlgeschlagener Download des Manifests oder einer verlangten Ressource das gesamte Update scheitern. Der bisherige Application Cache blieb aktiv. Auch nach einem erfolgreichen Download zeigte eine bereits geladene Seite nicht sofort die neue Fassung; sie musste neu geladen werden.

Das verhinderte eine Anwendung aus neuen und fehlenden Teilen. Gleichzeitig verschob es den Nachweis einer gelungenen Reparatur. Wer nur main.js ersetzte und das Manifest vergaß, ließ die alte Datei im Browser. Wer das Manifest änderte, aber eine Pflichtdatei nicht auslieferte, ließ ebenfalls die alte Anwendung dort. Der Serverzustand und die sichtbare Nutzerversion waren zwei verschiedene Befunde.

Zu ruhiges und zu hektisches Papier

Das Manifest konnte eine Änderung zu selten anzeigen. Es konnte sie auch zu oft anzeigen. Der Google-Leitfaden warnte davor, bei jeder Anfrage einen neuen Zeitstempel einzutragen. Der Browser konnte das Manifest zu Beginn und am Ende des Downloads prüfen. Ändert es sich dazwischen, könnten Dateien aus verschiedenen Revisionen stammen; der Browser wies das Paket dann zurück und versuchte es später erneut.

Die Abschnitte CACHE, NETWORK und FALLBACK regelten, was lokal blieb, was das Netz erreichen durfte und welche Ersatzseite bei einem Ausfall erschien. Eine kleine Textdatei legte damit die Netzpolitik der Anwendung fest. Eine fehlende Datei war nicht bloß ein kaputter Link; sie konnte ein komplettes neues Paket von der Installation ausschließen.

Der Browser bevorzugte einen vollständigen alten Stand gegenüber einem unvollständigen neuen. Für die Nutzung ohne Netz war das vernünftig. Für eine dringende Korrektur bedeutete es zusätzliche Arbeit: Das Team musste prüfen, ob der Leser tatsächlich die neue Fassung sah, nicht nur ob die Dateien auf dem Server lagen.

Chrome setzte der alten Regel ein Ende

Die Chrome-Anleitung zum Ausstieg von 2020 legte einen gestuften Ablauf fest. Chrome 85 schaltete AppCache standardmäßig ab; eine befristete Origin Trial gab betroffenen Seiten mehr Zeit. Service Worker wurden als anderer Weg zur Offline-Funktion genannt. Der Übergang hatte eine harte Grenze: Sobald ein Service Worker eine Seite in Chrome kontrollierte, arbeitete AppCache für diese Seite nicht mehr. Eine halb gebaute neue Caching-Lösung konnte die fehlende Hälfte nicht vom alten System ausborgen.

Anwendungen mussten neu festlegen, welche Anfragen behandelt, welche Dateien gespeichert und wie bereits geöffnete Seiten auf eine neue Version umgestellt würden. Google wies darauf hin, dass sein Übergangswerkzeug zwar Teile des AppCache-Verhaltens nachbildete, aber weder die Schnittstelle window.applicationCache noch ihre Ereignisse ersetzte. Chromes Zeitplan war der Takt eines Browsers und einer Migration, kein gemeinsamer Abschalttag aller Browser.

AppCache hatte eine klare Stärke: Eine Anwendung konnte ohne Verbindung weiter geöffnet werden. Die gleiche vollständige alte Kopie konnte nach der Rückkehr der Verbindung eine längst reparierte Anwendung verdecken. Zwischen Server und Leser saß das Manifest und bestimmte, wann die neue Fassung als Paket überhaupt antreten durfte.