Intent to Ship: Cache API for Service Worker
Kenji Baheux
Contact emails
kenji...@chromium.org, jsb...@chromium.org
Spec
Editor’s draft (W3C First Public Working Draft)
Summary
The Cache API for Service Worker consists of additional ServiceWorker APIs which allow authors to fully and conveniently manage their content caches for offline use. An origin can have multiple, named Cache objects, whose contents are entirely under the control of Service Worker scripts. One noteworthy edge that the Cache API has over the polyfill approach is its ability to handle opaque response.
We're proposing to ship a subset of what is defined in the spec (see this document for more details).
Link to “Intent to Implement” blink-dev discussion
https://groups.google.com/a/chromium.org/d/msg/blink-dev/Du9lhfui1Mo/HxL_pS7Cl-AJ
The spec and project used to be called Navigation Controller, but the name was changed to Service Worker. See also the Service Worker intent to ship.
Is this feature supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?
Yes.
Demo link
This is essentially the same demo featured in our Service Worker intent to ship (the demo uses a polyfill and is being updated to let native Cache APIs take over when available).
Debuggability
Developers can check the existence of caches and peek inside manually by inspecting the relevant Service Worker and issuing commands via the console.
Compatibility Risk
Pluses and minuses:
+ There's a first public working draft of the spec.
+ Mozilla is implementing Service Workers in Firefox, see bug 940273.
+ We semi-regularly reconcile the spec and our implementation. We have a defined process for that.
+ The team has been writing W3C testharness.js tests which we plan to upstream to W3C.
+ All the relevant closed or decided cache spec issues are tracked at crbug.com and triaged to minimize compatibility risk (unresolved impact MVP = 0; closed not tracked = 0; decided not tracked = 0; untriaged or unresolved = 0)
+ Based on observations from the spec issue triaging process, we believe that the scope of this intent to ship is fairly stable.
- We could not find any relevant tests in Firefox’s maple branch to cross check our Cache API implementation against
- The spec is under active development
OWP launch tracking bug?
Link to entry on the feature dashboard
https://www.chromestatus.com/feature/6461631328419840
Ben Kelly
> - We could not find any relevant tests in Firefox’s maple branch to cross
> check our Cache API implementation against
http://hg.mozilla.org/projects/maple/file/4a0fdfe4bd74/dom/tests/mochitest/cache
> + The team has been writing W3C testharness.js tests which we plan to
> upstream to W3C.
> + Based on observations from the spec issue triaging process, we believe
> that the scope of this intent to ship is fairly stable.
I think a shared/common test suite would help mitigate any risk from these spec gaps.
Just to clarify, you're only going to be exposing Caches on the ServiceWorker global for now, right?
Thanks!
Ben
Kenji Baheux
Our Cache tests are currently limited, but you can find what we have here:
http://hg.mozilla.org/projects/maple/file/4a0fdfe4bd74/dom/tests/mochitest/cache
Are these available anywhere yet? I would love to try them out against what I have for gecko.
Just to clarify, you're only going to be exposing Caches on the ServiceWorker global for now, right?
Ben Kelly
> >
> > Our Cache tests are currently limited, but you can find what we have here:
> >
> >
> > http://hg.mozilla.org/projects/maple/file/4a0fdfe4bd74/dom/tests/mochitest/cache
>
>
> Thanks, highly appreciated.
> I'll test our implementation against these and report back with results as
> soon as possible.
Similarly, I had difficulty running the blink tests because they use real ServiceWorkers (as you would expect). Unfortunately, I'm hitting issues in our SW implementation preventing the cache related code from even running.
I'll see if I can hack it a bit to run just the cache related bits tomorrow.
Thanks!
Ben
Ben Kelly
Unfortunately, though, the tests have revealed a bug in my implementation in gecko. Right now I'm incorrectly draining the Request body data on Match(). This is causing lots of failures since the tests reuse some Request objects for matching purposes.
I'll work on getting these tests green in gecko.
Thanks again for pointing me to them!
Ben
Ben Kelly
I finally get the blink tests running against gecko's maple development branch. I need to look at the results a bit more closely, but I did have one question so far.
In the cache-match.html test I see that it expects to be able to store responses for these three requests separately:
cat: {
request: new Request('http://example.com/cat'),
response: new Response('')
},
cat_with_fragment: {
request: new Request('http://example.com/cat#mouse'),
response: new Response('')
},
cat_in_the_hat: {
request: new Request('http://example.com/cat/in/the/hat'),
response: new Response('')
}
The URL attribute on Request, however, is supposed to ignore fragments as far as I can tell.
https://fetch.spec.whatwg.org/#dom-request-url
So shouldn't storing new Request('http://example.com/cat#mouse') be identical to new Request('http://example.com/cat')? Shouldn't this result in the second request/response pair overwriting the first pair?
In particular, this test seems wrong to me:
prepopulated_cache_test(simple_entries, function(cache) {
return cache.matchAll('http://example.com/cat',
{prefixMatch: true})
.then(function(result) {
assert_array_equivalent(
result,
[
simple_entries.cat.response,
simple_entries.cat_with_fragment.response,
simple_entries.cat_in_the_hat.response
],
'Cache.matchAll should honor prefixMatch.');
});
}, 'Cache.matchAll with prefixMatch option');
Sorry if I'm missing something obvious. Thanks for the help!
Ben
Ben Kelly
>
> I finally get the blink tests running against gecko's maple development
> branch. I need to look at the results a bit more closely, but I did have
> one question so far.
Based on his suggestion I wrote up the issues as bugs:
https://code.google.com/p/chromium/issues/detail?id=428965
https://code.google.com/p/chromium/issues/detail?id=428970
If I find anything else I'll write them up as well. I'll only post here if they effect things that blink expects to PASS.
Thanks again.
Ben
Jochen Eisinger
Chris Harrelson
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
