For ServiceWorker cache.addAll(), how do the URLs work?

Question

I see a lot of example code like this: (Slightly shortened version of this Mozilla Doc)

this.addEventListener('install', function(event) {
  event.waitUntil(
    caches.open('v1').then(function(cache) {
      return cache.addAll([
        '/sw-test/',
        '/sw-test/index.html',
        '/sw-test/style.css',
        '/sw-test/gallery/',
        '/sw-test/gallery/bountyHunters.jpg',
      ]);
    })
  );
});

I don't understand why you add both /sw-test/ and /sw-test/index.html. Seems like either the first folder URL should autoload everything underneath, or, if it doesn't do that, why is it there? Same for /sw-test/gallery/ and /sw-test/gallery/bountyHunters.jpg.

The docs say "The addAll() method of the Cache interface takes an array of URLs, retrieves them, and adds the resulting response objects to the given cache". Which isn't very helpful.

What I really want to do is cache all the *.html files from a few folders and all the image files (in various formats) from another folder. Listing them one-by-one is fragile (will quickly get out-of-sync), prone to typos, and is just plain silly.

Added Later

After further reading, doesn't seem like wildcards exist, so silly it is. :-) But whats the point of adding a folder like /sw-test/?

Answer 1

Yes, a wildcard doesn't exist and that's actually completely reasonable when you come to think of it: the web server doesn't expose the files found in a path (eg. /gallery/) so how could the browser cache files that it doesn't know the names for? A web server can of course be configured to expose the directory listings of a path but browsers themselves don't have any ability to "take everything from this path x". The directory/index listing is just a bunch of HTML, not any mapping of files or so.

Caching both / and /index.html is a bit confusing but from the Service Worker's standpoint they are different URLs. The web server is usually of course configured to serve same file (index.html) whichever URL you visit but if you ask the SW, they are separate and should have separate entries in the cache. This can be tested easily: deploy something that caches the / but not /index.html (even though the web server serves index.html from /) and try to visit /index.html in offline mode. No luck.

I don't think there's any reason at all to cache /index.html if you are completely sure your web app never makes any requests to it. If your web app only knows of / then leaving /index.html out should be completely fine. I've tested this myself and it works perfectly. If someone has more information on the matter, please correct me!

Something to note that could be useful: the SW may be configured to treat / and /index.html as the same. So caching / and serving it whenever either one is requested is possible. I guess some of the libraries has this sort of functionality built-in.

Answer 2

Building on pate's answer above: sw-precache and sw-toolbox are two libraries that are commonly recommended when implementing Service Workers as they allow for this wildcard functionality.