Re: [whatwg/fetch] HTTPS upgrades proposal (PR #1655)

@meacer commented on this pull request.



> + <li>
+  <p>Optionally, run <a>upgrade an HTTP request</a> algorithm on <var>request</var>.
+
+  <p class=note>HTTPS upgrading only applies to requests with <a>HTTP(S) scheme</a>s, but it's done
+  in <a>main fetch</a> instead of <a>HTTP fetch</a> to ensure that
+  <a>upgrade a mixed content <var>request</var> to a potentially trustworthy URL, if appropriate</a>
+  step runs next and applies to the upgraded request.
+

Apologies for the delay here.

If I'm understanding this correctly, having the referrer determined after the upgrade sounds like the correct behavior: If there was a successful HTTPS Upgrade, we don't want to drop the referrer even if the original link was http. So the fix needs to be made to the HSTS step, and not here, is that correct?

> Also reading this again the rationale here is flawed as HTTPS upgrading only applies when the destination is "document" whereas Mixed Content upgrading only applies for media destinations. So that needs fixing as well.

Another reason to have the upgrade called in main fetch was to keep it close to all other automatic upgrades (mixed content, hsts, UIR). Given that HTTPS upgrades is different than all of these because it only applies to document navigations, is the implication that we should also move it to network-or-cache-fetch like the fallback? Or can we just remove the justification and keep it here? 

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/1655#discussion_r1426359159
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/pull/1655/review/1781231193@github.com>