Issue metadata
Sign in to add a comment
|
Can't proceed through SSL interstitial if page was cached
Reported by
ascheg...@yandex-team.ru,
Mar 7 2018
|
||||||||||||||||||||
Issue description# Steps to reproduce: 1) Visit a page over https. Server should respond with headers "ETag" or "Last-Modified". 2) The page gets cached. On subsequent requests, browser sends "If-None-Match" or "If-Modified-Since" headers and server responds with "304 Not modified". 3) Server certificate expires, or another overridable certificate error occurs. 4) Click "Proceed" on SSL interstitial # What is the expected result? The page shows. # What happens instead of that? Nothing happens. "Proceed" button doesn't hide the interstitial. HttpCache::Transaction adds conditional headers before the network connection and never changes them. After RestartIgnoringLastError browser sends those conditional headers and server responds with "304 Not modified". However in HttpCache::Transaction::WriteResponseInfoToEntry browser checks IsCertStatusError and calls StopCachingImpl. As a result, browser gets no response body from the server and cannot use the cached response. I'm not sure how to fix that - either strip conditional headers somewhere in HttpNetworkTransaction::BuildRequestHeaders, or do not call StopCachingImpl if we've got 304.
,
Mar 7 2018
,
Mar 7 2018
I think this is actually very similar to issue #6697. The trouble is that certificate errors resume in the middle of the HttpCache::Transaction flow. They probably ought to start over from the top instead, which would also allow releasing the cache lock. I don't know how feasible that is. (Cache folks?) On the other hand, committed interstitials (issue #448486) would move that retry outside URLRequest, so we'd just get this behavior for free, at least for navigation requests. We could then lose the ContinueDespiteLastError flow altogether, and replace it with some sort of net-side cache of host decisions (in turn allowing us to fix the livelock issues around socket pools), which should in turn clear out the subresources issue... ...and I really should write up those discussions we had over in Zurich. :-)
,
Mar 7 2018
,
Mar 26 2018
ascheglov@ Does this still happen if you turn on chrome://flags/#committed-interstitials to enable committed interstitials?
,
Mar 29 2018
No it doesn't. Enabling committed interstitials does fix the problem.
,
Mar 31 2018
Hopefully committed interstitials (for SSL errors) at least will launch in 68 or thereabouts so this will be fixed then. (Just one CL that needs to land.) |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by csharrison@chromium.org
, Mar 7 2018