Bug 142831 – The network cache should ignore "cache-control: no-cache, must-revalidate" on history navigation

• Component: Page Loading
• Status: RESOLVED FIXED

[Chris Dumez]

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>

[Chris Dumez]

Created attachment 249010 [details]
Patch

[Chris Dumez]

Created attachment 249011 [details]
Patch

[WebKit Commit Bot]

Comment on attachment 249011 [details]
Patch

Clearing flags on attachment: 249011

Committed r181734: <http://trac.webkit.org/changeset/181734>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Carlos Garcia Campos]

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?

[Carlos Garcia Campos]

(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.

[Chris Dumez]

(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.

[Carlos Garcia Campos]

(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.

[Carlos Garcia Campos]

(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.