Open Malvoz opened 5 years ago
Oh and to clarify, whilst you should not rev these files, the natural question is how do we as developers (instantly) update them then?
serviceworker.js
Browsers may store the response for up to 24h before considered stale and will not revalidate the response unless the updateViaCache
attribute is set to all
. Once opted in to HTTP Cache revalidation, the serviceworker file should respond with the no-cache
cache-control directive, asking the client to validate it with the server on page loads.
Furthermore, "Use the skipWaiting()
method with Clients.claim()
to ensure that updates to the underlying service worker take effect immediately for both the current client and all other active clients."
Edit: The newly introduced sw for Google Search does it that exact same way: https://web.dev/google-search-sw/#solution:-balance-freshness-and-cache-utilization
More info:
https://developers.google.com/web/fundamentals/primers/service-workers/lifecycle#updates
https://developers.google.com/web/updates/2018/06/fresher-sw
.webmanifest
That's not all that clear (aside from a user re-installing the PWA?), as the issue I linked to in my first comment is the sole issue trying to solve how developers can update the manifest - without introducing ways for developers to abuse the fact that a user may have a PWA installed but a malicious developer updates (e.g.) icons to trick a user~.
I've been bitten by this so many times... I believe we still have some issue with the manifest in webhint.io and one of the icons not existing anymore (or something like that).
So this should be a change in http-cache
that should also not tell you to set a long-lived cache for those assets I assume.
A user can now avoid the http-cache for a specific URL via the ignoredUrls
property but we should add some defaults. Question is: should we add another option to expand these defaults or point users to the ignoredUrls
property?
Also we should look at the most common names for service workers. Probably need to query HTTPArchive for that.
@webhintio/contributors thoughts?
Thanks!
Also we should look at the most common names for service workers. Probably need to query HTTPArchive for that.
When browsers support it, you could check for the serviceworker
request destination (and manifest
respectively) as advertised in the Sec-Fetch-Dest
HTTP header.
It's currently available behind #enable-experimental-web-platform-features
in Chrome.
It's common for developers to version resources (call it: fingerprinting, url hashing, file revving, url query string parameters etc.). This may cause issues for some types of files, which to my knowledge include:
Serviceworkers: https://developers.google.com/web/fundamentals/primers/service-workers/lifecycle#avoid-url-change
Webmanifests: https://github.com/w3c/manifest/issues/446#issuecomment-351368893
Related issue(?): https://github.com/webhintio/hint/issues/1307
As for the potential hint implementation, I assume that because serviceworkers do not have a unique MIME type I suppose you'd want to look for the common file-names
sw.js
,service(-/_)worker.js
. And although Web App Manifest defines theapplication/manifest+json
for.webmanifest
it is common for developers to usemanifest.json
aswell.✌️