Bug 139251 - Allow HTTPS + 'Cache-control: no-cache' pages into the page cache
Summary: Allow HTTPS + 'Cache-control: no-cache' pages into the page cache
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: History (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Chris Dumez
URL:
Keywords:
Depends on: 139263
Blocks:
  Show dependency treegraph
 
Reported: 2014-12-03 22:20 PST by Chris Dumez
Modified: 2015-01-05 20:50 PST (History)
8 users (show)

See Also:


Attachments
Patch (6.84 KB, patch)
2015-01-05 14:14 PST, Chris Dumez
no flags Details | Formatted Diff | Diff
Archive of layout-test-results from ews101 for mac-mountainlion (509.03 KB, application/zip)
2015-01-05 14:59 PST, Build Bot
no flags Details
Archive of layout-test-results from ews106 for mac-mountainlion-wk2 (510.19 KB, application/zip)
2015-01-05 15:03 PST, Build Bot
no flags Details
Patch (8.12 KB, patch)
2015-01-05 15:07 PST, Chris Dumez
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Dumez 2014-12-03 22:20:56 PST
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
Comment 1 Alexey Proskuryakov 2014-12-03 22:33:48 PST
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.
Comment 2 Chris Dumez 2014-12-03 22:36:56 PST
(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.
Comment 3 Alexey Proskuryakov 2014-12-03 23:41:39 PST
Weird, I didn't know this. I wonder why - allowing HTTPS pages in page cache is relatively new, so this should be new, too.
Comment 4 Antti Koivisto 2014-12-04 06:30:10 PST
Yeah, only no-store should stop caching.
Comment 5 Chris Dumez 2014-12-04 09:42:11 PST
(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.
Comment 6 Alexey Proskuryakov 2014-12-04 09:52:12 PST
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.
Comment 7 Chris Dumez 2014-12-04 10:15:02 PST
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.
Comment 8 Antti Koivisto 2014-12-04 15:35:31 PST
"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).
Comment 9 Chris Dumez 2015-01-05 14:14:36 PST
Created attachment 244003 [details]
Patch
Comment 10 Build Bot 2015-01-05 14:59:17 PST
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
Comment 11 Build Bot 2015-01-05 14:59:20 PST
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
Comment 12 Build Bot 2015-01-05 15:03:51 PST
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
Comment 13 Build Bot 2015-01-05 15:03:56 PST
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
Comment 14 Chris Dumez 2015-01-05 15:07:17 PST
Created attachment 244008 [details]
Patch
Comment 15 WebKit Commit Bot 2015-01-05 20:50:08 PST
Comment on attachment 244008 [details]
Patch

Clearing flags on attachment: 244008

Committed r177948: <http://trac.webkit.org/changeset/177948>
Comment 16 WebKit Commit Bot 2015-01-05 20:50:13 PST
All reviewed patches have been landed.  Closing bug.