[ServiceWorker] Pattern for handling fingerprinted assets? (#657)

Is there any discussion around handling fingerprinted assets in the SW cache? Say your app's build process adds a fingerprint to an asset’s filename like `style-3b491f3c.css`. And when you update that file, the next version of it is named `style-9b9c2a06.css`.

I get that Service Workers would remove the need for fingerprinting files like that, but for people who already have their build process in place/want fingerprinting where SW is not supported...what might be the best pattern for handling this?

Initially I imagine you have to:

Search the cache for a "match" on your asset `style-9b9c2a06.css`, regardless of a matching fingerprint

If an exact match is found (the fingerprints are equal):
1) return the cached resource and call it a day.

If an exact match *isn't* found, but an older version of the resource is available (`style-3b491f3c.css`): 
1) return this resource from the cache
2) fetch the newer version `style-9b9c2a06.css` from the network for later
3a) if the network request succeeds, add `style-9b9c2a06.css` to the cache, and remove the old resource `style-3b491f3c.css`
3b) if the network request fails, just keep using the old version and call it a day.

Talked with @wanderview briefly about this and he mentioned there used to be a `prefixMatch` to support similar use cases, but it was nixed because of complexity/inefficiency/lameness. 

Perhaps solving this is decidedly outside the scope of the spec for the time being -- in which case I'll just write something to sit on top -- but I also wouldn't be surprised if this turns out to be a more common issue.

---
Reply to this email directly or view it on GitHub:
https://github.com/slightlyoff/ServiceWorker/issues/657