[Hint] Avoid URL-versioning for some files

[Malvoz]

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: Specify how updates work w3c/manifest#446 (comment)

Related issue(?): #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 the application/manifest+json for .webmanifest it is common for developers to use manifest.json aswell.

✌️

[Malvoz]

Oh and to clarify, whilst you should not rev these files, the natural question is how do we as developers (instantly) update them then?

For 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

For .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~.

[molant]

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!

[Malvoz]

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.