virtuelles FileSystem mit CacheAPI - wie würdet ihr es umsetzen

[Michael_K]

Hallo,

ich habe eine Zip-Datei mit HTML-Seiten und separaten CSS Files und Grafiken. Die Zip-Datei wird mit input form ausgewählt. Die Zip-Datei soll dann entpackt werden und der Browser den Inhalt anzeigen. Das Ganze soll lokal passieren, d.h. nichts zum Server senden.

Ich möchte das über die CacheAPI lösen. Soll heissen, ein Service-Worker fängt die fetch-Anfrage ab, wenn der Pfad der URL mit "zipContent" anfängt, und sendet dann die zuvor in den Cache eingeladenen Dateien als response. Für mich stellt sich die Frage, welche url-Addresse die sinnvollste wäre. Aktuell tendieren ich dazu, den Inhalt der Zip-Datei in ein verzeichnis abzulegen, wobei das Verzeichnis den Hash-Wert der Zip-Datei entspricht.

Also etwa so https://[server.domain]/zipContent/[ziphash]/[entspricht_dem_rootverzeichnis]

Was würde gegen diese Vorgehensweise sprechen?

Gruß Michael

[Rolf B]

Hallo Michael_K,

der Origin-Teil der URL (Protokoll, Domain, Port) muss eh zur Site passen, sonst bekommt der Serviceworker nichts mit.

Den Rest mach so, dass Du normalen URLs, die am Server liegen, nicht in die Quere kommst. Wenn zipContent für Dich passt - warum nicht. Du könntest den virtuellen Ordner auch $zip oder @cache nennen (👉 Wiki).

Ich habe sowas auch schon gebaut, für Frickl 2.0 - was aus Gründen auf Halde liegt...

Beachte aber, dass der Application Cache nicht unbegrenzt groß ist. Bei LocalStorage hast Du 5MB garantierte Obergrenze, beim Cache hängt es vom Speicherdruck auf dem System ab. Es kann durchaus sein, dass der Browser Dir Cache-Einträge eben mal wegputzt, d.h. dein Serviceworker muss - wie bei anderen Cache-Einträgen auch - die Möglichkeit zum Reload der Daten haben.

Rolf

[Michael_K]

Der Hinweis mit dem gelöschten Cache ist gut. Das muss in der Tat bedacht werden. Bis jetzt hatte ich nur auf meiner Liste, dass Service Worker nicht zwingend vom Browser sichergestellt werden und der Browser diese auch selbst schliessen kann.