[w3c/ServiceWorker] Clarify CacheStorage behavior in data: URL workers (Issue #1644)

#687 noted that the spec was unclear regarding how `self.caches` and `CacheStorage` in data URL workers should be handled, and the [resolution](https://github.com/w3c/ServiceWorker/issues/687#issuecomment-208506905) to that issue was to add the `SecureContext` web IDL attribute to `self.caches` and `CacheStorage`.  I don't think this sufficiently addresses what to do in the case of data URL workers, though, because AFAICT data URL workers can be considered a secure context.  For instance, if a worker is created from a data URL by https://example.com/, per [1] it seems like the worker would also be considered a secure context.

As currently written, it seems like the spec indicates that `self.caches` and `CacheStorage` should be exposed for data URL workers in secure contexts, but all of the functions should fail because:
 - the `CacheStorage` interface member functions all use `relevant name to cache map` [2]
 - `relevant name to cache map` uses `obtain a storage key` [3], which will "returns failure" if the environment has an opaque origin
 - data URL worker environments have opaque origins [4]

It's unclear to me given the current spec language what effect the 'obtain a storage key' failure should have.

As discussed in #687, perhaps it'd be worth updating the spec to just not expose `self.caches` and `CacheStorage` in the context of data URL workers?  This is what Chrome does today.

[1] https://html.spec.whatwg.org/multipage/webappapis.html#secure-contexts
[2] https://w3c.github.io/ServiceWorker/#dfn-relevant-name-to-cache-map
[3] https://storage.spec.whatwg.org/#obtain-a-storage-key
[4] https://html.spec.whatwg.org/multipage/workers.html#set-up-a-worker-environment-settings-object



-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1644
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/1644@github.com>