[Webkit-unassigned] [Bug 153230] Network cache: old pages returned by disk cache on history navigation after session is restored

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=153230

--- Comment #14 from Carlos Garcia Campos <cgarcia at igalia.com> ---
Let me explain what I think it's the desired behavior here, at least for GTK:

 - For any BF navigation we always want stale data. If the page is in the page cache, that should always be used, if the page cache is disabled, then the memory cache, and if it's not in the memory cache, then stale data from the disk cache.

 - For a BF navigation of an item that was restored from the session as requested by the API, we always want stale data from the page cache or the memory cache, but not from the disk cache. So, it's considered a normal load only by the disk cache. This not only affects the BF navigation that happens right after restoring the session, but also to any other history item created by the session restore.

The reasoning. We use the session restore for 3 different features in epiphany:

 1 - To restore a previous session at startup. In this case, there won't be page cache nor memory cache, so we will always end up in the disk cache. We don't want stale data in this case, users expect the browser to show updated contents. Not expired  resources are of course revalidated and loaded from the cache in any case.

 2 - To restore recently closed tabs. In this case we want to use stale data from any cache. It's not a problem if the history item is marked as normal load, because unless there's a web process crash, the resources will be in the page cache or memory cache (it's a recently closed tab)

 3 - In ephy, when you open a new a link in a new tab or window, the bf list is inherited, so that you can go back to the page from which the link was clicked. In this case, as in the previous one, we always want stale data from any cache, but we expect the resources to be in the page or memory cache. 

In the very unlikely case of not having the resources in the page or memory cache in cases 2 and 3, we would be doing a unnecessary revalidation, for resources that will very likely not be expired, so we will end up loading from the disk cache anyway. The unnecessary revalidation in these cases wouldn't be a problem for us at all.

Even id this is based on the particular cases of the epiphany browser, I think this is the desired behavior of any of our API users. If anybody complains we can always add a setting to enable/disable this from the API, but I don't think that's going to happen. 

Hope it's clearer now.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20160204/1bec3c4f/attachment.html>