Workbox: Support for overriding URL used when writing to the cache

[zmrdlb]

Welcome! Please use this template for reporting bugs or requesting features. For questions about using Workbox, the best place to ask is Stack Overflow, tagged with [workbox]: https://stackoverflow.com/questions/ask?tags=workbox

Library Affected:
workbox-sw

Browser & Platform:
Google Chrome v69.0.3497.100 for mac

Issue or Feature Request Description:
I set matchOptions:{ignoreSearch: true} in workbox.strategies.networkFirst. It indicates I think the response of special page doesn't be affected by query string or hash. ex. When I request /another.html, /another.html?query string, /another.html#hash, I expect it has only one cache for /another.html. How can I do?

When reporting bugs, please include relevant JavaScript Console logs and links to public URLs at which the issue could be reproduced.

[jeffposnick]

It sounds like you want to alter the outgoing request to strip everything other than the pathname, and then use that modified URL for both cache matching and updates to the cache.

You can do that with a requestWillFetch() plugin:

const myPlugin = {
  requestWillFetch: ({request}) => {
    const newUrl = new URL(request.url);
    newUrl.search = '';
    newUrl.hash = '';
    return new Request(newUrl.href, {headers: request.headers});
  },
};

workbox.routing.registerRoute(
  new RegExp('/some/pattern'),
  workbox.strategies.networkFirst({
    cacheName: 'my-cache',
    plugins: [myPlugin],
  })
);

Hopefully that works for you—I'll reopen this issue if not.

[bortojac]

The above solution does not appear to prevent additional cache entries of the unaltered url.

Using the above, I still see entries of:

• /some/pattern.html
• /some/pattern.html?query_string1
• /some/pattern.html?query_string2

How might we prevent these additional entries from being cached?

[jadjoubran]

Have you tried setting the ignoreUrlParametersMatching to /.*/? By default it's only set to handle utm_ query strings.
An easier way to test would be the following:

1. Check if /some/pattern.html?utm_source=a2hs creates a new entry
2. If it doesn't, it's because of ignoreUrlParametersMatching
3. Then you can customize those or just set it to a wildcard /.*/

[bortojac]

Currently I am only using runtime caching with the workbox.routing and workbox.strategies libraries. Is it possible to use the ignoreUrlParameters option on requests to files that have not been precached?

I was able get the desired functionality using a custom match function and a custom handler, but I wonder if it is possible to modify the request before it is cached using a custom plugin. I tried using the requestWillFetch plugin, however altering the request there does not prevent the original fetchEvent.request url (with query params) from being cached.

[jeffposnick]

I reopened this in recognition that we need to hook into the process within Workbox that writes to the caches to support overriding the default URL. Apologies that I indicated you could do this with just requestWillFetch alone, as that only handles one half of the equation (the reading, not the writing).

[zhixuanziben]

@zmrdlb I meet the same problem too, How do you slove this problem?

[zhixuanziben]

I am sorry that the workbox does not support this feature, so I fall back to the basic serviece worker, here is my code, you can refer to it, the idea is to rewrite the search request, so the read cache and write cache are based on the modified URL. I hope it can help you.

self.addEventListener('fetch', event => {
 // Just cache html document
  if (event.request.mode === 'navigate') {
    event.respondWith(
      caches.open('rent-cache-v1').then(function(cache) {
        const normalizedUrl = new URL(event.request.url);
        normalizedUrl.search = '?car_id=123';
        return cache.match(normalizedUrl).then(function(response) {
          const fetchPromise = fetch(normalizedUrl, {
            credentials: 'include'
          }).then(function(networkResponse) {
            if (networkResponse.status === 200) {
              cache.put(normalizedUrl, networkResponse.clone());
            }
            return networkResponse;
          });
          return response || fetchPromise;
        });
      })
    );
  }
});

[jeffposnick]

Here's a proposal that I think could address this use case:

async function cacheKeyWillBeUsed({request, mode}) {
  // request is the default Request object that would otherwise be used as the cache key.
  // mode is either 'read' or 'write', depending on whether it's a read or a write.
  // Return either a string, or a Request whose url property will be used as the cache key.
  // Returning the original request will make this a no-op.
}

I kind of like the approach of using a single callback with a mode parameter that could be used if needed, or otherwise ignored, since I think for most of the time you'll end up wanting to make the same transformation regardless of whether it's a match or put.

It still remains to be seen whether this plugin would run in relation to the other lifecycle events, but my inclination is fairly early on, and then the revised cache key Request would be passed in to the other subsequent events.

What do folks think?

[mdiblasio]

This approach looks great and will solve for the use-case of modifying the URLs (e.g. to append a time-based param) without modifying the actual network request. The mode is a nice option to have, but agree in most cases you'll make the same transformation.

[jeffposnick]

Edit: I'm going to go with 'read' and 'write' for the two mode values, since those make a bit more sense generically vs. 'match' and 'put', which only make sense if you know what the underlying Cache Storage API methods are.