Summary: | Allow HTTPS + 'Cache-control: no-cache' pages into the page cache | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Chris Dumez <cdumez> | ||||||||||
Component: | History | Assignee: | Chris Dumez <cdumez> | ||||||||||
Status: | RESOLVED FIXED | ||||||||||||
Severity: | Normal | CC: | ap, barraclough, beidson, buildbot, commit-queue, kling, koivisto, rniwa | ||||||||||
Priority: | P2 | ||||||||||||
Version: | 528+ (Nightly build) | ||||||||||||
Hardware: | Unspecified | ||||||||||||
OS: | Unspecified | ||||||||||||
Bug Depends on: | 139263 | ||||||||||||
Bug Blocks: | |||||||||||||
Attachments: |
|
Description
Chris Dumez
2014-12-03 22:20:56 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. (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. Weird, I didn't know this. I wonder why - allowing HTTPS pages in page cache is relatively new, so this should be new, too. Yeah, only no-store should stop caching. (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. 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. 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. "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). Created attachment 244003 [details]
Patch
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 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 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 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
Created attachment 244008 [details]
Patch
Comment on attachment 244008 [details] Patch Clearing flags on attachment: 244008 Committed r177948: <http://trac.webkit.org/changeset/177948> All reviewed patches have been landed. Closing bug. |