Bug 139251 – Allow HTTPS + 'Cache-control: no-cache' pages into the page cache

• Status: RESOLVED
• Resolution: FIXED
• Component: History

[Chris Dumez]

Always ignore 'Cache-control: no-cache' on back/forward navigation, as Internet Explorer 10+ [1] and Google Chrome [2] do, and as allowed by RFC2616 [3] & newer RFC7234 [4] (both RFCs distinguish history mechanisms and caches).

Currently, we only ignore 'Cache-control: no-cache' on back/forward navigation for HTTP pages, not HTTPS ones. My proposal is to extend this policy to HTTPS pages as those are becoming increasingly common, similarly to what IE10+/Chrome do.

Sensitive sites (such as banking sites) can still use 'Cache-control: no-store' to prevent resource reuse in forward/back navigations.

On a side note, Firefox still does not ignore HTTPS+no-cache for back/forward navigations [5].

[1] http://blogs.msdn.com/b/ieinternals/archive/2012/03/01/ie10-beta-consumer-preview-minor-changes-changelist.aspx (I also confirmed this manually with IE11)
[2] https://code.google.com/p/chromium/issues/detail?id=152752 (I also confirmed this manually with Chrome 39)
[3] http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.13
[4] http://tools.ietf.org/html/rfc7234#section-6
[5] https://bugzilla.mozilla.org/show_bug.cgi?id=567365

[Alexey Proskuryakov]

Is this about pages that are not in page cache for some reason? HTTP headers don't affect page cache, so these are already cacheable.

[Chris Dumez]

(In reply to comment #1)
> Is this about pages that are not in page cache for some reason? HTTP headers
> don't affect page cache, so these are already cacheable.

From PageCache.cpp:
===
    if (frame->document()->url().protocolIs("https")
        && (frame->loader().documentLoader()->response().cacheControlContainsNoCache()
            || frame->loader().documentLoader()->response().cacheControlContainsNoStore())) {
        PCLOG("   -Frame is HTTPS, and cache control prohibits caching or storing");
        rejectReasons |= 1 << IsHttpsAndCacheControlled;
    }
===

We don't put them in page cache AFAICT.

[Alexey Proskuryakov]

Weird, I didn't know this. I wonder why - allowing HTTPS pages in page cache is relatively new, so this should be new, too.

[Antti Koivisto]

Yeah, only no-store should stop caching.

[Chris Dumez]

(In reply to comment #3)
> Weird, I didn't know this. I wonder why - allowing HTTPS pages in page cache
> is relatively new, so this should be new, too.

This was done by Brady in https://bugs.webkit.org/show_bug.cgi?id=26777. The reason mentioned in the Changelog is that this matches the behavior of Firefox's bfcache. As mentioned in this bug's description, Firefox's bfcache still does not cache HTTPS+no-cache pages.

However, I still think we should allow HTTPS+no-cache into the page cache as this is increasingly common. The RFC says that the freshness model does not necessarily apply to history mechanisms. As such, we don't necessarily have to revalidate in case of back/forward navigation. In any case, we already allow "HTTP+no-cache" into the page cache and I think it makes sense to extend this policy to "HTTPS+no-cache". "no-store" can still be used anyway to not allow sensitive pages into the page cache.

[Alexey Proskuryakov]

Right, neither no-cache nor no-store have effect on page cache per the RFC. I don't know if there is any effort to standardize the no-store behavior that you plan to preserve.

[Chris Dumez]

BTW, there also seems to be a difference in behavior in our disk caching of HTTPS + no-cache between Safari and IE10+/Chrome.

Steps:
1. Load https://www.alain.knaff.lu/bug-reports/mozillaNoStore/
2. Click 'no-cache' link (write down the date on the no-cache page)
3. Click 'continue' link
4. Press back button to navigate back
5. Check the date on the no-cache page

Result:
- With Safari, the date has changed which means the page was reloaded from the server
- With IE10 and latest Chrome, the date doesn't change (expected behavior), which means it was reused from the cache.

The no-cache page returns the following HTTP headers:
Cache-Control:no-cache, max-age=604800
Content-Encoding:gzip
Content-Length:246
Content-Type:text/html
Date:Thu, 04 Dec 2014 17:31:49 GMT
Last-Modified:Thu, 01 Jan 1970 00:00:00 GMT
Server:Apache/2.2.22 (Ubuntu)
Vary:Accept-Encoding

Interestingly, if you repeat steps 3 to 5 once more in Safari, then the page actually gets reused from the cache. I am no sure which it gets loaded from the cache only on the second time we navigate back to that page.

P.S: You may need to make an exception for the certificate of the test page (it has expired) as certificate errors may affect caching.

[Antti Koivisto]

"The purpose of the no-store directive is to prevent the inadvertent release or retention of sensitive information." 

Even for persistent storage it could be argued that no-store resources can be cached as long as the storage is secure (for the purpose of back/forward navigation and tab restore).

[Chris Dumez]

Created attachment 244003 [details]
Patch

[Build Bot]

Comment on attachment 244003 [details]
Patch

Attachment 244003 [details] did not pass mac-ews (mac):
Output: http://webkit-queues.appspot.com/results/5051805184557056

New failing tests:
http/tests/navigation/https-in-page-cache.html

[Build Bot]

Created attachment 244006 [details]
Archive of layout-test-results from ews101 for mac-mountainlion

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews101  Port: mac-mountainlion  Platform: Mac OS X 10.8.5

[Build Bot]

Comment on attachment 244003 [details]
Patch

Attachment 244003 [details] did not pass mac-wk2-ews (mac-wk2):
Output: http://webkit-queues.appspot.com/results/5032675400220672

New failing tests:
http/tests/navigation/https-in-page-cache.html

[Build Bot]

Created attachment 244007 [details]
Archive of layout-test-results from ews106 for mac-mountainlion-wk2

The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: ews106  Port: mac-mountainlion-wk2  Platform: Mac OS X 10.8.5

[Chris Dumez]

Created attachment 244008 [details]
Patch

[WebKit Commit Bot]

Comment on attachment 244008 [details]
Patch

Clearing flags on attachment: 244008

Committed r177948: <http://trac.webkit.org/changeset/177948>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.