Skip to content
This repository has been archived by the owner on Jan 23, 2021. It is now read-only.

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

Open
chenav opened this issue Apr 21, 2016 · 3 comments
Milestone

Comments

@chenav
Copy link

chenav commented Apr 21, 2016

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

@wibblymat wibblymat mentioned this issue May 24, 2016
@jeffposnick
Copy link
Contributor

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

@chenav
Copy link
Author

chenav commented May 26, 2016

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
Copy link
Contributor

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants