Application Cache

aus Wikipedia, der freien Enzyklopädie

Der Application Cache ist ein Standard, der einen besonderen Browser-Cache für Webseiten, vor allem Webanwendungen zur Verfügung stellt. Der Standard wurde mit HTML5 eingeführt und soll auf einfache Weise ermöglichen, dass Seiten auch offline genutzt werden können. In der Praxis zeigten sich allerdings zahlreiche Schwächen, sodass der Standard inzwischen als hinfällig gilt.[1]

Funktionsweise

Der Application Cache ist ein Speicherbereich, in dem der Webbrowser bestimmte Ressourcen speichert, die von einer Seite benötigt werden, damit diese beim nächsten Besuch sofort zur Verfügung stehen, auch wenn zu diesem Zeitpunkt keine Internetverbindung besteht. Er funktioniert damit ähnlich wie der gewöhnliche Browser-Cache und wird parallel zu diesem eingesetzt.

Welche Ressourcen gespeichert werden sollen, wird mit dem Cache Manifest bestimmt. Das Manifest gibt außerdem an, ob fehlende Ressourcen über das Internet heruntergeladen werden sollen oder ob stattdessen ein Fallback verwendet werden soll.

Um ein Cache Manifest zu verwenden, wird dessen URL im manifest-Attribut des <html>-Tags notiert. Der Browser wird beim ersten Aufruf der Seite alle Ressourcen herunterladen, die im Manifest angegeben sind, und diese cachen. Bei jedem weiteren Besuch werden diese Ressourcen nicht mehr über das Internet geladen, sondern direkt aus dem Cache geholt. Anschließend prüft der Browser, ob sich die Manifest-Datei in der Zwischenzeit geändert hat. Ist dies der Fall, so wird er den Cache aktualisieren, diese neue Version wird allerdings erst beim nächsten Besuch der Seite oder nach einem Neuladen aktiv.

Zudem gibt es eine JavaScript-Schnittstelle, über die die Seite mittels Events verfolgen kann, in welchem Zustand sich der Cache befindet.

Cache Manifest

Das Cache Manifest ist eine einfache Textdatei mit der Dateiendung .appcache und dem MIME-Type text/cache-manifest, die mit der Kennzeichnung CACHE MANIFEST beginnt. Kommentare sind Zeilen die mit einem Doppelkreuz (#) beginnen. Der Rest der Datei besteht aus Einträgen von drei verschiedenen Typen: explizite Cache-Einträge (in einem Abschnitt mit der Überschrift CACHE: oder außerhalb gekennzeichneter Abschnitte), Fallback-Einträge (in einem Abschnitt mit der Überschrift FALLBACK:), sowie Netzwerk-Einträge (in einem Abschnitt mit der Überschrift NETWORK:). Die Abschnitte können in beliebiger Reihenfolge und auch mehrfach oder gar nicht vorkommen.

Alle als explizite Cache-Einträge gelisteten URLs sowie die Einträge, die implizit dadurch gecachet werden, dass sie das Manifest einbinden, werden in den Cache aufgenommen. Fallback-Einträge bestehen aus einem URL-Bereich und der Angabe einer Fallback-URL. Kann eine Ressourcen aus einem dort gelisteten Bereich nicht geladen werden, so wird stattdessen der Fallback verwendet. Netzwerk-Einträge geben schließlich an, welche Ressourcen bei Verwendung des Application Caches trotzdem über das Internet geladen werden sollen. Das Standard-Verhalten ist, dass alle Ressourcen, die nicht im Manifest verzeichnet sind, automatisch fehlschlagen, selbst wenn eine Internetverbindung besteht. Dieses Verhalten kann aber über einen Netzwerk-Eintrag * als Wildcard oder spezifischere Angaben zu diesen Ressourcen geändert werden.

Beispiel

Als Beispiel soll eine Seite dienen, die es dem Benutzer ermöglicht, sich durch mehrere Bilder hindurchzublättern. Diese Bilder sollen dabei nicht alle von Anfang an sichtbar sein, sondern dynamisch nachgeladen werden. Dazu wird eine CSS-Stildatei style.css und ein JavaScript-Skript script.js eingesetzt, sowie die Bilder bild1.jpg bis bild4.jpg.

Die HTML-Datei könnte (wenn das Skript für den kompletten Inhalt verantwortlich ist) folgendermaßen aussehen:

<!DOCTYPE html>
<html manifest="cache.appcache">
 <head>
  <title>Bilderbuch</title>
  <link rel="stylesheet" href="style.css">
  <script src="script.js"></script>
 </head>
 <body>
 </body>
</html>

Die in der zweiten Zeile angegebene Cache-Datei könnte den folgenden Inhalt haben:

CACHE MANIFEST
#v1
script.js
style.css
bild1.jpg
bild2.jpg
bild3.jpg
bild4.jpg

Die HTML-Datei wird implizit gecachet, da sie das Manifest einbindet, dazu kommen die CSS- und die JS-Datei sowie die vier Bilder. Diese werden geladen, obwohl sie zu diesem Zeitpunkt noch nicht benötigt werden, da sie nicht direkt in der HTML-Datei referenziert werden.

Wird eine der Dateien aktualisiert, so muss die Manifest-Datei geändert werden. Sofern die Liste der Dateien gleich geblieben ist, bietet es sich an, einen Kommentar zu modifizieren und so eine neue Version zu erzeugen. Dazu dient die zweite Zeile im Manifest-Beispiel.

Sicherheit

Unterhalb der Adresszeile ist ein Dialog eingeblendet mit: "Diese Website (gabrielecirulli.github.io) speichert nun mehr als 0MB Daten auf ihrem Computer zur Verwendung im Offline-Modus."
Nachfrage in Firefox, ob eine Seite (2048) den Application Cache verwenden soll

Der Application Cache ermöglicht es Benutzer ähnlich wie mit Cookies zu verfolgen. Zudem besteht die Möglichkeit, sehr viel Speicherplatz zu verbrauchen. Damit bösartige Seiten dies nicht ausnutzen, fragen die meisten Browser beim Benutzer nach, bevor sie erstmals für eine Seite einen Application Cache anlegen. Je nach Browser gibt es auch unterschiedliche Möglichkeiten den Cache wieder zu entfernen.[2]

Browserunterstützung

Alle aktuellen Browser unterstützen Application Cache, Mozilla Firefox ab Version 3.5, der Internet Explorer ab Version 10, Google Chrome ab Version 4. In Android besteht ab Version 2.1 Unterstützung im Standardbrowser.[3]

Firefox zeigt ab der Version 44 eine Warnung in der Browserkonsole an, wenn Application Cache eingesetzt wird, um Programmierer darauf aufmerksam zu machen, dass es sich um eine veraltete Technologie handelt.[4]

Probleme

In der Praxis zeigten sich zahlreiche Probleme mit dem Application Cache:[5]

  • Ändert sich eine Datei im Cache, so müssen alle Dateien neu heruntergeladen werden.
  • Ein sinnvoller Einsatz ist nur bei einer überschaubaren Zahl von zu cachenden Ressourcen möglich. Zwar gibt es Ansätze, wie Application Cache auch für Internetangebote wie Wikipedia eingesetzt werden kann,[6] die sehr viele Seiten haben, von denen ein einzelner Benutzer jedoch nur wenige nutzt, aber dabei würde der Cache zum einen sehr viel Speicherplatz verbrauchen, zum anderen würden dem Benutzer häufig veraltete Seiten gezeigt.
  • Wird das Cache Manifest zu lange gecachet (im normalen Browser-Cache oder sogar im Application Cache selbst), so ist eine Aktualisierung unmöglich. Selbst wenn der Programmierer der Webseite seinen Fehler nachträglich bemerkt, hat er keine Möglichkeit ihn zu korrigieren.
  • Stellt eine Seite bestimmte Ressourcen in verschiedenen Formaten bereit (etwa Videos in verschiedenen Codecs oder Bilder in unterschiedlichen Auflösungen für variierende Bildschirmgrößen), so muss der Browser alle Formate herunterladen und cachen.

In einigen Fällen weichen Programmierer daher auf andere Technologien aus, etwa Web Storage. Als Reaktion auf diese Probleme wurde der Service-Worker-Standard entworfen,[7] der allerdings deutlich komplexer ist und noch nicht in allen Browsern implementiert ist. Seit 2015[8] wird der Application Cache von der WHATWG als deprecated eingestuft.[1] Setzt eine Seite sowohl Service Worker als auch Application Cache ein, so ignorieren moderne Browser den Application Cache.

Einzelnachweise

  1. a b HTML Standard. Offline Web applications. WHATWG, abgerufen am 25. Juli 2016 (englisch).
  2. Using the application cache. Storage location and clearing the offline cache. In: MDN Web Docs. Abgerufen am 25. Juli 2016 (englisch).
  3. Can I Use: Offline web applications. Abgerufen am 25. Juli 2016.
  4. Firefox 44 for developers. In: MDN Web Docs. Abgerufen am 25. Juli 2016 (englisch).
  5. Jake Archibald: Application Cache is a Douchebag. In: A List Apart. 8. Mai 2012, abgerufen am 25. Juli 2016 (englisch).
  6. Offline Web Applications - Dive Into HTML5. In: diveintohtml5.info. Abgerufen am 25. Juli 2016.
  7. Service Workers. Motivations. W3C, abgerufen am 25. Juli 2016 (englisch).
  8. Deprecate <keygen> and appcache. 28. August 2015, abgerufen am 25. Juli 2016.

Weblinks