Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Revamp HTTPS-First Mode fallback mechanism
This CL changes how HTTPS-First Mode and HTTPS Upgrades trigger a fallback navigation to HTTP. Before this change, the NavigationThrottle would cancel the failed navigation and post an async task to start a new navigation to the fallback URL. This generally worked, but had (at least) three issues: (1) this could cause "double counting" of navigations, (2) it's hard to create a new navigation out of an old one without missing important parameters (and maintain that over time), and (3) it's possible for race conditions to occur on the frame being navigated. To avoid these issues, this CL changes the fallback mechanism to instead intercept the failing navigation via NavigationLoaderInterceptor::MaybeCreateLoaderForResponse() to serve an artificial redirect back to the fallback URL directly, as part of the same overall navigation. This means no new navigation is created (avoiding double counting), no state is lost on the navigation (it's just like the site itself served a downgrade redirect), and there is no period where one navigation is canceled and another is not yet created in which races could occur. As the HTTPS-First Mode/HTTPS Upgrades logic is currently implemented in chrome/, this exposes the MaybeCreateLoaderForResponse() API on URLLoaderRequestInterceptor and adds an implementation to HttpsUpgradesInterceptor. As a result, a lot of the logic from HttpsUpgradesNavigationThrottle moves into HttpsUpgradesInterceptor. The SetNavigationTimeout() implementation also needs to be modified to trigger NavigationURLLoaderImpl::OnComplete() rather than NotifyRequestFailed(), as the latter skips directly to the failure state and does not trigger the interceptor's MaybeCreateLoaderForResponse(). There are still known issues with how the new fallback implementation interacts with (1) redirect loops and (2) tracking fallback state across navigations. The first can result in briefly seeing a network error for TOO_MANY_REDIRECTS before the HTTPS-First Mode interstitial is triggered. The second can result in an incorrect security state being computed for a tab where a fallback to HTTP had previously occurred. Fixes for these issues will be handled in followup CLs. Bug: 1394910 Change-Id: Ib53c8f873a30e6b2ebb933ae527a5c7f5fcd9bcd Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4199590 Commit-Queue: Chris Thompson <cthomp@chromium.org> Reviewed-by: Alex Moshchuk <alexmos@chromium.org> Reviewed-by: Mustafa Emre Acer <meacer@chromium.org> Cr-Commit-Position: refs/heads/main@{#1105469}
- Loading branch information