Bug 1231565 added support for the HTTP cache to store "alternative data type" streams in support of caching parsed JS representations (serialized in their XDR form) for bug 900784. DOM cache should plan to support this so sites switching to ServiceWorkers don't experience performance regressions in JS loading versus a fully-HTTP cached site. The implementation is likely to also be important to WASM in the future since it should allow the compiled form to be opportunistically or explicitly cached along-side the canonical body response. (Currently, our IndexedDB implementation supports storage of compiled WASM modules via structured clone. But this might not end up the standard way to do so... in https://github.com/WebAssembly/design/issues/972#issuecomment-276877682 the Google Chrome team has indicated they've disabled IndexedDB persistence of WASM modules.) WASM is likely to favor directly receiving a file descriptor that could potentially be mmapp'ed rather than a stream, so that should ideally be factored into any implementation changes.

I had some thoughts on this in bug 900784 comment 66.

HoPang is working on this, assigning to him, thanks!

If you need help for the API, Valentin Gosu did the implementation as part of the Necko, and I used it in the ScriptLoader. If you want to test using the ScriptLoader, you can ask me, or have a look at the test case: http://searchfox.org/mozilla-central/rev/b258e6864ee3e809d40982bc5d0d5aff66a20780/dom/base/test/test_script_loader_js_cache.html

Thanks Nicolas, The testcase indeed helped me a lot in bug 1350359 ;)

Hi Eden, Though the patches cannot be applied directly, I believe they still can be used as references and reminder for the discussion we had a couple days ago. In additional to the patches, we still need to plumb the IPDL and modify the implementation of match() to retrieve the saved alternative data from the DOM cache. Besides, we still need a testcase for that, which could be similar to the one in bug 1350359. We just need to save the response carrying the alternative data to DOM cache and retrieve it.

Reusing the test case in test_script_loader_intercepted_js_cache.html. In this test, file_js_dom_cache.html will be loaded three times. For the first time, get the data by fetching from the network, and script loader will save the alternative data into http cache. For the second time, get the data from http cache by calling fetch again, and ServiceWorkerScript will save the alternative data into the dom cache. For the third time, get the response from dom cache directly. And the same result with the second time load is expected.

Since alternativeBody and nsICacheInfoChannel will be accessed multiple times when synthesizing the response and saving the data into the dom cache, we need to keep them in InternalResponse. This patch also supports clone the alternative data and cacheInfoChannel when calling InternalResponse::Clone.

This patch supports to save the alternative body and nsICacheInfoChannel information while putting request/response pair into the dom cache. In fact, this patch doesn't save the whole nsICacheInfoChannel into the dom cache, it only saves the needed raw data for loading alternative body by script loader.

Supports to load saved alternative data and nsICacheInfoChannel information from the dom cache while executing match operations. CachedCacheInfoChannel is a limited nsICacheInfoChannel implementation for script loader reading the alternative data, since it is hard to restore the real nsICacheInfoChannel without open a real channel.

I'm sorry I didn't get to this review today. I will do it tomorrow morning.

(In reply to Ben Kelly [:bkelly] from comment #14) > I'm sorry I didn't get to this review today. I will do it tomorrow morning. I didn't do it the next morning! I think I can say I won't have time for these reviews. The patches should probably be rebased before review at this point as well.

General question: if a Response is clone()d and one Response gets stored in the Cache and the other Response is fed to the JS script loader (or, with bug 1487113, WebAssembly.compileStreaming()) and thereby gains alt-data in the HTTP Cache, would the Cache.put() be able to "take" the alt-data from the HTTP Cache so that it doesn't have to be regenerated a second time? Otherwise, to avoid this recompilation, iiuc, the developer would: cache.add(url).then(() => fetchEvent.respondWith(cache.match(url))) which seems a bit sub-optimal.

Talking with Eden, he's not actively working on this but still in his plan.