"Properly" means: when an http channel is possibly intercepted, use a specific nsICacheStorage impl*) that will not give the channel the entry until it's pre-filled synthetically or will just forward to the a normal cache storage when interception is canceled. The "proper" thing is that we have to go around the normal cache semantics _in the channel_ and not in the cache. What also means to not let the channel mess with the entry sooner it's "finalized". This is a rough outline. *) That impl will take an interceptor object that will be notified about every cache entry being open and will be able to fill it - asynchronously, and eventually give to the storage back to be given to the channel. Makes sense? Other option is definitely to do more hacks in http channel to use something else than the http cache. Similar approach I highly disliked on appcache - polluting the http channel code. There was not much way around with appcache, but today we can do better.

We no longer use http cache for service worker interception. This was fixed in bug 1391693.