Cache-Busting, bei dem der Service-Mitarbeiter nicht unterstützt wird

Question

Ich verwende sw-precache und sw-toolbox, um meinen Service-Mitarbeiter zu verwalten. Lassen Sie uns sagen, dass ich eine CSS-Datei, die ich

staticFileGlobs: ['public/asset/build/css/m_index.min.css'] 

gecached werden sollen Es gets hinzugefügt, um die Servicemitarbeiter auf Lauf schluck Aufgabe als

var precacheConfig = [["public/asset/build/css/m_college.min.css","8d9b0e69820ba2fab83c45e2884bd61f"] 

Der Hash der Datei hilft mir in Cachebusting wenn Service Arbeiter ist registriert. Alles funktioniert gut.

Betrachten Sie nun eine Situation, in der ein bestimmter PC oder Benutzer oder Browser den Service Worker nicht registrieren kann und die Datei ihm jedes Mal über das Netzwerk zugestellt wird. In diesem Fall wird die Datei im Speicher des Browsers gespeichert, da standardmäßig kein Cache-Fehler auftritt. Und es könnte die alte Datei diesem Benutzer lebenslang zuführen, selbst nachdem der Entwickler die Datei aktualisiert hat.

Wie ist der Umgang mit diesem Szenario?

Answer 1

Für alle, die nach Antworten suchen, gibt es eine einfache Lösung - COOKIES.

Beim Versuch, Cookie zu registrieren, wenn etwas fehlschlägt, setzen Sie einen Cookie. Dieser Cookie kann vor dem Senden von Dateien im Backend gelesen werden. Wenn der Cookie nicht gesetzt ist, laden Sie Dateien ohne Cache-Busting, sonst fügen Sie am Ende einen Cache-Buster an, um Browser-Caching zu verhindern, wenn Service Worker nicht läuft.

Weil Cookies das einzige Ding sind, das direkt auf Frontend und Backend zugänglich ist.

Answer 2

Ich würde die Etag-Antwort-Header (https://developer.mozilla.org/en/docs/Web/HTTP/Headers/ETag) verwenden, um das Laden veralteter Assets für Benutzer zu vermeiden.