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

@annevk approved this pull request.

@mozfreddyb that would result in an upgrade. Once we see a redirect response we go back into main fetch. That also applies to navigation, although that is a bit more involved.

@meacer are there tests for that scenario?

> +<p id=example-https-upgrade-good-https class=example><code>a.com</code> serves both
+<code>http://a.com</code> and <code>https://a.com</code>. An eligible request to
+<code>http://a.com</code> will be upgraded to <code>https://a.com</code>.
+
+<p id=example-https-upgrade-bad-https class=example><code>a.com</code> serves
+<code>http://a.com</code> but refuses connections on <code>https://a.com</code>. An eligible
+request to <code>http://a.com</code> will be upgraded to <code>https://a.com</code>, but the fetch
+will fail. A fallback request will be initiated to <code>http://a.com</code>.
+
+<p id=example-https-upgrade-allowlist class=example><code>site.test</code> serves
+<code>http://site.test</code> but refuses connections on <code>https://site.test</code>. Upon
+first request and fallback to <code>http://site.test</code>, the user agent stores the hostname
+in an allowlist with an expiration time of 7 days. In a future request, if <code>site.test</code>
+is still in this allowlist, the user agent will not upgrade <code>http://site.test</code> to
+<code>https://site.test</code>. The user agent will also set the new expiration time of the
+allowlist entry for <code>site.test</code> to 7 days from now.

Newlines are being eaten here.

> +<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 was hoping for examples around what types of hosts, but if it's more heuristic-based today I don't think it's needed.

We only need origin here if we think people might want to use the port to determine whether or not to upgrade. I could see not wanting to upgrade ports other than the default port, for instance, but not sure if anyone is planning that. Maybe leave this as-is for now and revise if it comes up?

It would not constrain you just taking the host out of the origin and making decisions based on that. As you say, it makes it more flexible.

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

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