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

@meacer commented on this pull request.



> +<div algorithm>
+<p>To <dfn>upgrade an HTTP request</dfn> given a <a for=/>request</a> <var>request</var>:
+
+<ol>
+ <li>
+  <p>If one or more of the following conditions are met, return:
+  <ul>
+   <li><p><var>request</var>'s <a for="request">destination</a> is not "<code>document</code>"
+
+   <li><p><var>request</var>'s <a for="request">method</a> is not "<code>GET</code>"
+
+   <li><p><var>request</var>'s <a for="request">URL</a>'s <a for="url">scheme</a> is not
+   "<code>http</code>"
+
+   <li><p><var>request</var>'s <a for="request">URL</a>'s <a for="url">host</a> is exempted from
+   upgrades in an <a>implementation-defined</a> way.

I added an example in the examples section below for an allowlisting case. Happy to add more.

Speaking of allowlisting: It's currently hostname-based in Chrome for a few reasons:
- It matched how certificate error decisions were stored for SSL interstitials
- Making it hostname based, thus overly inclusive, reduced the risk of breakage. Failing an upgrade once opts out the entire site from upgrades again for the allowlisting duration. 
- The allowlist is shared with Chrome's HTTPS-First Mode which shows an interstitial before falling back to HTTP. So making it more fine grained could result in more interstitials and lead to warning fatigue.

That said, I think we can relax this and give more leeway to UAs. If we say origin here, but the UA still decides to exempt based on hostname only, would that be acceptable or non spec compliant?

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

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