The network cache should ignore "cache-control: must-revalidate" on history navigation. On history navigation, it currently tries to revalidate such resources if they have expired. However, the RFC does not require us to do so [1]: """ User agents often have history mechanisms, such as "Back" buttons and history lists, that can be used to redisplay a representation retrieved earlier in a session. The freshness model (Section 4.2) does not necessarily apply to history mechanisms. That is, a history mechanism can display a previous representation even if it has expired. """ Chrome and IE9+ [2] already ignore "cache-control: must-revalidate" on history navigation. [1] https://tools.ietf.org/html/rfc7234#page-32 [2] http://blogs.msdn.com/b/ie/archive/2010/07/14/caching-improvements-in-internet-explorer-9.aspx Radar: <rdar://problem/20209957>
Created attachment 249010 [details] Patch
Created attachment 249011 [details] Patch
Comment on attachment 249011 [details] Patch Clearing flags on attachment: 249011 Committed r181734: <http://trac.webkit.org/changeset/181734>
All reviewed patches have been landed. Closing bug.
This has a side effect in case of restoring session. When restoring the session, the back forward list is restored, but pages are not in page cache nor in memory cache, but they could be in the history cache. So, when navigating the history after a session restore we can end up with old versions of pages loaded from the disk cache. This happens to me in bugzilla, for example, when I open the browser and tabs from previous session are restored, I don't see the changes made in the bugs since the last session, and I have to manually reload the pages to get the current version. So, I think this is good policy for memory cache, but not for disk cache. Doesn't this happen in Safari too?
(In reply to comment #5) > This has a side effect in case of restoring session. When restoring the > session, the back forward list is restored, but pages are not in page cache > nor in memory cache, but they could be in the history cache. I meant they could be in the disk cache.
(In reply to comment #5) > This has a side effect in case of restoring session. When restoring the > session, the back forward list is restored, but pages are not in page cache > nor in memory cache, but they could be in the history cache. So, when > navigating the history after a session restore we can end up with old > versions of pages loaded from the disk cache. This happens to me in > bugzilla, for example, when I open the browser and tabs from previous > session are restored, I don't see the changes made in the bugs since the > last session, and I have to manually reload the pages to get the current > version. So, I think this is good policy for memory cache, but not for disk > cache. Doesn't this happen in Safari too? This change was intentional and yes it happens in Safari too. The rationale was that we are *restoring* a session and as such the user could expect the pages to be exactly those that he was viewing last time. Revalidating them could cause us to display different (i.e. fresher) content, which could be annoying to users that expected their previous content to be *restored*. This behavior is also beneficial to battery life as it avoids a lot of network activity on browser startup and the user can choose to refresh only the tab he/she cares about and only if he/she wants to. Note that a different behavior could be implemented at browser level, without modifying our network cache code. The browser could simply use a non history-navigation cache policy when restoring a session.
(In reply to comment #7) > (In reply to comment #5) > > This has a side effect in case of restoring session. When restoring the > > session, the back forward list is restored, but pages are not in page cache > > nor in memory cache, but they could be in the history cache. So, when > > navigating the history after a session restore we can end up with old > > versions of pages loaded from the disk cache. This happens to me in > > bugzilla, for example, when I open the browser and tabs from previous > > session are restored, I don't see the changes made in the bugs since the > > last session, and I have to manually reload the pages to get the current > > version. So, I think this is good policy for memory cache, but not for disk > > cache. Doesn't this happen in Safari too? > > This change was intentional and yes it happens in Safari too. The rationale > was that we are *restoring* a session and as such the user could expect the > pages to be exactly those that he was viewing last time. Revalidating them > could cause us to display different (i.e. fresher) content, which could be > annoying to users that expected their previous content to be *restored*. > This behavior is also beneficial to battery life as it avoids a lot of > network activity on browser startup and the user can choose to refresh only > the tab he/she cares about and only if he/she wants to. > > Note that a different behavior could be implemented at browser level, > without modifying our network cache code. The browser could simply use a non > history-navigation cache policy when restoring a session. Problem is that a non history navigation would add the current item again to the fb list. I guess we could use a filter to restore the bf list and skip the current item, though.
(In reply to comment #8) > > Problem is that a non history navigation would add the current item again to > the fb list. I guess we could use a filter to restore the bf list and skip > the current item, though. Filtering wouldn't work either, the problem in this case is that we would lost the forward list after a normal navigation. Another weird thing I've just noticed with webkit bugs is that once the old contents are loaded, if I click in the bug link so that the page is loaded, I can see the new comments and the change in patch falgs, etc., but the EWS boxes are not updated unless I reload the page with CTRL + F5.