The http/tests/cache/disk-cache-validation.html layout test is failing on GTK+ since r179449 (http://trac.webkit.org/changeset/179449). This test enables the tests for cache funcionality. The output is the following: FAIL: Timed out waiting for notifyDone to be called
*** Bug 141702 has been marked as a duplicate of this bug. ***
*** Bug 141703 has been marked as a duplicate of this bug. ***
*** Bug 142818 has been marked as a duplicate of this bug. ***
Will consolidate the GTK TestExpectations via https://bugs.webkit.org/show_bug.cgi?id=142979.
Mac has recently enabled NETWORK_CACHE (See bug 30322) by default on r179449 <ttp://trac.webkit.org/changeset/179449> Should GTK also enable it?
(In reply to comment #5) > Mac has recently enabled NETWORK_CACHE (See bug 30322) by default on r179449 > <ttp://trac.webkit.org/changeset/179449> > > Should GTK also enable it? We first need to implement it :-) We also need to figure out what to do with the single web process model, I guess we could keep using the soup cache in the web process and the WebKit cache in the network process. Or we could make the single web process model become a multiple web process model with limit = 1, and the network process will always be used.
(In reply to comment #6) > Or we could > make the single web process model become a multiple web process model with > limit = 1, and the network process will always be used. Note that a properly-sandboxed web process would not have any access to the network, so mandatory network process is something we'd come to eventually anyway. (Also, it would make Apple happy, but you know that.)
These are the slides from Antti's talk at the WK Contributors Meeting. https://trac.webkit.org/attachment/wiki/March%202015%20Meeting/Disk%20cache.pdf The main requirements are implementing NetworkCache::IOChannel and NetworkCache::Data. In GLib/GIO this might be possible by using GFile and GMemoryInputStream/GMemoryOutputStream (or whatever best replicates dispatch_io_* and dispatch_data_* APIs).
(In reply to comment #6) > We first need to implement it :-) We also need to figure out what to do with > the single web process model, I guess we could keep using the soup cache in > the web process and the WebKit cache in the network process. Or we could > make the single web process model become a multiple web process model with > limit = 1, and the network process will always be used. Mandatory network process is something I would be willing to implement, for bug #140075.
(In reply to comment #9) > (In reply to comment #6) > > We first need to implement it :-) We also need to figure out what to do with > > the single web process model, I guess we could keep using the soup cache in > > the web process and the WebKit cache in the network process. Or we could > > make the single web process model become a multiple web process model with > > limit = 1, and the network process will always be used. > > Mandatory network process is something I would be willing to implement, for > bug #140075. The question is whether sandboxing will be mandatory as well, or just optional. There are use cases in embedded world where network process, caches, and sandboxing are not needed at all.
The initial implementation of the disk cache for soup landed in r183387. It works and all tests pass, but it hasn't been extensively tested yet. It can still be improved by using shareable resources, for example, but the only blocker is bug #144251 (to ensure all cache files are created with a creation time). So, I would like to enable the disk cache as soon as bug #144251 is fixed, so that we can start testing it now (early in the release cycle).
Created attachment 252373 [details] Patch No more blockers, we are ready.
Comment on attachment 252373 [details] Patch Nice.
Committed r183865: <http://trac.webkit.org/changeset/183865>