Feature request: Treat HSTS redirects as a URL rewrite in Blink |
|
Issue descriptionWe'd like to treat HSTS redirects as a URL rewrite in Blink to avoid latency costs associated with those redirects. It isn't always possible for links to be automatically re-written by developers, so we could consider doing this in Chrome. Additional context: https://groups.google.com/a/chromium.org/forum/#!msg/net-dev/oEA0gae22A0/lUhOL8HxEgAJ https://docs.google.com/document/d/1aJuojFjfcuAvAJxa3Nne0ck-Vm3yCaZlx98mV2ReT7E/edit#heading=h.5eu2xbrf49lw (for Googlers) lassey@ found that we already do this for preconnects https://cs.chromium.org/chromium/src/chrome/browser/net/predictor.cc?q=HSTS&sq=package:chromium&l=798
,
Apr 5 2018
A few thoughts, in no particular order: 1. Fetch models HSTS as a rewrite (step 4.9 of https://fetch.spec.whatwg.org/#main-fetch), so this is, in theory, what we already ought to be doing. No browser I know of does it that way, of course, so we'd need to be a little careful with the implementation to ensure that we didn't create web-visible differences in behavior. 2. I don't believe Blink currently has the ability to rewrite the URLs of redirect targets (because the hooks the network stack offers allow cancellation, but not modification). This has created some problems for our Upgrade-Insecure-Requests implementation, which I'd like to be able to fix. 3. How are y'all thinking about getting the preload list into Blink? Shared memory mapped into each renderer? 4. Would this help us address the long-standing issues with WebRequest and HTTPSEverywhere being blocked by mixed content checks?
,
May 7 2018
See Issue 823542 for some additional context. |
|
►
Sign in to add a comment |
|
Comment 1 by igrigo...@google.com
, Apr 5 2018