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

@meacer commented on this pull request.



>  
+   <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.
+
+    <p class=example id="example-https-upgrades-exempted-hosts">If <a for=url>host</a> is a
+    non-registrable or non-assignable domain name such as .local or an IP address that falls in a
+    range reserved for non-publicly routable networks, the implementation might return without
+    modifying <var>request</var>.

We discussed this more, and decided to remove the exemption for non-unique hostnames from upgrades in Chrome. There are a few reasons for this:
- The original reason for excluding these hostnames was that they were unlikely to serve valid HTTPS. However, this isn't universally true: developers may want to test and debug on environments where short names can serve valid HTTPS. We want to enable this use case.
- Browsers may (and most likely should) implement an allowlisting scheme where they don't try upgrades on a hostname if an upgrade failed on that hostname to avoid load time regressions (this is made possible by the "implementation-defined" wording above). In this scenario, an upgrade attempt on a non-unique hostname would only be done once every N days (current N=7 in Chrome, may change soon). So enabling HTTPS-Upgrades on non-unique hostnames should not cause a significant performance regression.
- As a side benefit, removing this carveout will make writing web platform tests for HTTPS-Upgrading possible. When run locally, WPTs are served on a non-unique hostname so HTTPS-Upgrades don't apply.

So I'm removing this example, but please let me know if you feel strongly otherwise.

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

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

Received on Tuesday, 24 October 2023 05:59:15 UTC