potential http cache issues with importScripts() #894
Comments
|
Hmm, I agree. We should use the same cache mode for |
|
Maybe this is something chrome is already doing, but I don't think we do it in firefox right now. Kind of a sharp edge waiting to catch someone. |
|
Pre F2F notes: The |
|
F2F:
|
|
Gecko bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1290939 Sounds like chrome already does this. |
I'd like to double-check this behavior. The main script "skipping cache" is different from the main script "changed". I believe the model has been a service worker version holds until the main script itself is changed. In this proposed change, do we want to include all the to-be-imported-scripts for calculating the byte-by-byte match decision for short-circuiting a registration? Then, if an imported script has been changed, will we see this set of scripts as a different service worker version? Advancing to Install in this case seems weird to me. |
|
Note that in the current spec behavior, the imported scripts are served from the cache without hitting the network once the installation is successfully complete for a service worker version. |
|
Sorry. In my previous two comments, I completely missed this history: #839 (comment). I'll dig into it again with that context and consensus considered. |
This introduces service worker registration's use cache field and its
related APIs: options.useCache to register method and
registration.useCache for ServiceWorkerRegistration objects. This
changes the default cache mode of fetching SW scripts to "no-cache".
After the change, 24 hours limit and job's force bypass cache flag rules
are still enforced. register() method's options value set to
{ useCache: true } re-enables the previous default behavior provided
before this change.
Fixes #893 #894.
|
Closed by 7deb238. |
Currently the spec says to use RequestCache
reloadwhen updating the service worker script if its been over 24 hours since the last update check. I don't however, see anything about bypassing the http cache for files fetched forimportScripts(). I think this could lead to http cache coherence problems when loading and evaluating a service worker script thats split across multiple files.Edit: My statement about the default http cache behavior in gecko was not accurate.
The text was updated successfully, but these errors were encountered: