GoogleChromeLabs / sw-precache

[Deprecated] A node module to generate service worker code that will precache specific resources so they work offline.
https://developers.google.com/web/tools/workbox/guides/migrations/migrate-from-sw
Apache License 2.0
5.22k stars 388 forks source link

Require the RegExp request-matching syntax (without options.origin) in runtimeCaching #108

Open chenav opened 8 years ago

chenav commented 8 years ago

Hey,

I tried to configure external domain caching through the runtimeCaching feature of sw-precache.

I used the options syntax for the external domain conf passed to the array runtimeCaching:

{ urlPattern: /\/(.*)/, handler: 'fastest', options: { cache: { name: 'googleapis', maxAgeSeconds: 864000 }, origin: /\.googleapis\.com$/ } }

It was translated after grunt execution into (in the service-worker.js): toolbox.router.get(/\/(.*)/, toolbox.fastest, {"cache":{"name":"googleapis","maxAgeSeconds":864000},"origin":{}});

As you can see, the origin parameter is an empty object and then, at runtime, everything is cached into the "googleapis" cache. Which is wrong :)

I then tried to declare the origin with quotes:

origin: '/\.googleapis\.com$/'

After grunt execution, it generated : toolbox.router.get(/\/(.*)/, toolbox.fastest, {"cache":{"name":"googleapis","maxAgeSeconds":864000},"origin":"/.googleapis.com$/"});

Looks better (even if it changed my regExp). But at runtime, all requests of my own domain get cached in the 'googleapis' cache. Even the already precached ones. It works as if the origin had no effect (or is wrong, which is expected since the regExp has been changed).

I tried the same configuration straight into a mint sw-toolbox (outside of sw-precache) with this declaration: toolbox.router.get('/(.*)', toolbox.fastest, { cache: { name: 'googleapis', maxAgeSeconds: 864000 }, origin: /\.googleapis\.com$/ });

It works perfectly, only files from the googleapis.com domain are stored in the 'googleapis' cache. My own domain files are stored in other caches, as expected.

I may be completely wrong, but it seems that the origin attribute is not well accepted by sw-precache 3.1.1 in the runtimeCaching. A turnaround I found, was to put a mint sw-toolbox (3.1.1) and a custom-rules.js (for my rules) file in the importScript part of sw-precache. It works fine that way, but it is not a 'all-in-one' grunt approach.

It leads me to the question:
Does the runtimeCaching (with sw-toolbox embedded) feature support the origin option of the sw-toolbox ? if so, what is the syntax ?

Thanks !

Chenav

jeffposnick commented 8 years ago

This should be resolved in https://github.com/GoogleChrome/sw-precache/releases/tag/3.2.0. Can you confirm?

chenav commented 8 years ago

Mmmmh, I could not make it work.

I updated sw-precache and I built a project with that syntax in my gruntfile:

capture d ecran 2016-05-26 a 22 39 56

Does not work properly at run time, as the 'googleapis' cache collects every fetch.

The service-worker.js file generated by the grunt still contains that expression (which "origin" attribute is wrong and does not filter the 'googleapis.com' domain: it is empty - weird !):

capture d ecran 2016-05-26 a 22 45 24

I do not think my syntax is wrong (it works in mint sw-toolbox), but I'll be glad if you could check. It feels like the origin attribute does not like the reg exp on the domain name

jeffposnick commented 8 years ago

Sorry for the misinformation re: https://github.com/GoogleChrome/sw-precache/releases/tag/3.2.0

I think I see what's going on, and it should be able to work around this if you use the urlPattern option to match on the full URL, like:

urlPattern: /\.googleapis\.com\//,

(feel free to tweak that RegExp if you need to be more restrictive).

The whole different-behaviors-when-using-strings-vs.-RegExp thing is unfortunate, and I apologize for that. I know that there are folks who are in favor of using strings for "routes" when using sw-toolbox directly, but I have a feeling that folks who are using sw-toolbox indirectly via runtimeCaching would benefit from just having a single, consistent approach, and that would rely on RegExps.

I'll leave this open to track that change.