When a cache_storage Response is returned from a service worker fetch event handler for a script, the v8 code cache may trigger this code:

https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/loader/fetch/resource.cc?l=178&rcl=70c422048c104b20c547bd4da7b3f4e52aa82234

This sends a message back to the browser with the code cache metadata, the cache name, and the ResponseResponse::Url().  That cache name and URL are then used to look up a DiskCacheEntry in cache_storage to store the metadata in.

This works well for the common case where the fetch event handler does something like:

  evt.respondWith(caches.match(evt.request));

However, its possible for the service worker script to run arbitrary js and return Response objects not generated in this way.

For example, consider a service worker that stores different Responses for different modes:

  let mode = GetMode();
  evt.respondWith(caches.match(evt.request.url + '?mode=' + mode));

In this case the message to store the cached metadata will not find an entry.  What is worse, though, is its possible there will be an entry, but for a different script than what was actually returned to the page.

I have not been able to explicitly trigger the v8 code cache heuristics to test this, but I did instrument ServiceWorkerCachedMetadataSender.  I can see that it uses the wrong URL on this page:

  https://sw-cache-switcheroo.glitch.me/

Even if the URL was updated, though, there would still be potential for problems.  For example, a new script could be written to the same URL and result in the cached metadata being wrong.

To fix this we should probably plumb a unique identifier for the cache_storage entry that can be used to store against only the specific entry that the v8 compiler saw.

Marking this restrict-view for now since I'm unsure if its a security issue.