Address comments

Author: meacer

fetch.bs

@@ -3251,37 +3251,37 @@ steps:
 
 <h4 id=https-upgrades-upgrade>Upgrade algorithm</h4>
 
-<p>Given a request <var>request</var>, this algorithm will rewrite its URL if the request should be
-modified and loaded over <code>"https"</code>, via the following algorithm:
+To <dfn>upgrade an HTTP request</dfn> given a <a for=/>request</a> <var>request</var>, run these
+steps:
 
 <ol>
   <li>
     <p>If one or more of the following conditions are met, return without modifying request:
     <ul>
-      <li><p><var>request</var> is not a navigation request whose destination is document</li>
-
-      <li><p><var>request</var>'s method is not `<code>GET</code>`</li>
+      <li><p><var>request</var>'s <a for="request">destination</a> is "<code>document</code>"
 
-      <li><p><var>request</var>'s URL's scheme is not <code>"http"</code></li>
+      <li><p><var>request</var>'s <a for="request">method</a> is not "<code>GET</code>"
 
-      <li><p><var>request</var>'s URL's host is non-unique (i.e., contains 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)</li>
+      <li><p><var>request</var>'s <a for="request">URL</a>'s <a for=url>scheme</a> is not
+      "<code>http</code>"
 
-      <li><p>Optionally, <var>request</var>'s URL's host is exempted from upgrades by the user agent
-      </li>
+      <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. For example, 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>.
     </ul>
   </li>
 
   <li><p>If <var>request</var>'s <code>https-upgrade-fallback-url</code> is non-null, this is a
   fallback request that shouldn't be upgraded again. Clear the <code>https-upgrade</code> and
-  <code>https-upgrade-fallback-url</code> flags and return <var>request</var>.</li>
+  <code>https-upgrade-fallback-url</code> flags and return.
 
   <li><p>Otherwise, upgrade the request by setting the following fields:
     <ul>
-      <li>Set <code>https-upgrade-fallback-url</code> to request's URL</li>
-      <li>Set <var>request</var>'s URL's scheme to <code>"https"</code></li>
-      <li>Set <code>https-upgrade</code> flag to true</li>
+      <li>Set <code>https-upgrade-fallback-url</code> to request's URL
+      <li>Set <var>request</var>'s URL's scheme to <code>"https"</code>
+      <li>Set <code>https-upgrade</code> flag to true
     </ul>
   </li>
 </ol>
@@ -3291,30 +3291,27 @@ modified and loaded over <code>"https"</code>, via the following algorithm:
 <p>Runs after the Upgrade algorithm. This algorithm determines whether the upgraded
 request completed without a network error. If not, it retries the request over <code>"http"</code>.
 
+To <dfn>handle an HTTPS upgrade fallback</dfn> given a <a for=/>request</a> <var>request</var>, run
+these steps:
+
 <ol>
-  <li><p>If the <code>https-upgrade</code> flag is not set, return without modifying request.</li>
+  <li><p>If <var>request</var>'s <code>https-upgrade</code> flag is not set, return without
+  modifying request.
 
   <li><p>Otherwise, this is an upgraded request. Let <var>upgradedResponse</var> be the result of
-  fetching the upgraded request.</li>
+  fetching the upgraded request.
 
   <li>
-    <p>If <var>upgradedResponse</var> is a network error, initiate a fallback http load by doing the
-    following:
+    <p>If <var>upgradedResponse</var> is a network error, initiate a fallback load by creating a
+    synthetic redirect response <var>fallbackResponse</var> that redirects to <var>request</var>'s
+    <code>https-upgrade-fallback-url</code> flag with status 307. Return
+    <var>fallbackResponse</var>.
 
-    <ul>
-      <li><p>Set <var>request</var>'s URL to the value of <var>request</var>'s
-        <code>https-upgrade-fallback-url</code> flag</li>
-
-      <li><p>Set response to the result of running <a>HTTP-redirect fetch</a> given fetchParams and
-        <var>upgradedResponse</var>.</li>
-    </ul>
-  </li>
-
-  <li><p>Otherwise, the upgrade was successful. Return <var>upgradedResponse</var>.</li>
+  <li><p>Otherwise, the upgrade was successful. Return <var>upgradedResponse</var>.
 </ol>
 
-<p>
-Optionally, user agents may implement a fast-fallback option by canceling slow fetches on upgraded
+<p class=note>
+User agents may implement an optional fast-fallback path by canceling slow fetches on upgraded
 requests and quickly initiate a fallback http load. 
 
 </div>
@@ -3336,15 +3333,6 @@ requests and quickly initiate a fallback http load.
   A fallback request will be initiated to <code>http://a.com</code>.
 </div>
 
-<div id=example-https-upgrade-slow-https class=example>
- <p>
-  Optional fast-fallback example: <code>a.com</code> serves <code>http://a.com</code> and loads very
-  slowly over <code>https://a.com</code>.
-  An eligible request to <code>http://a.com</code> will be upgraded to <code>https://a.com</code>.
-  If the upgraded request doesn't return a response for N seconds, the fetch will be canceled.
-  A fallback request will be initiated to <code>http://a.com</code>.
-</div>
-
 <h2 id=http-extensions>HTTP extensions</h2>
 
 <h3 id=origin-header>`<code>Origin</code>` header</h3>
@@ -4523,7 +4511,7 @@ steps:
 
  <li><p><a>Upgrade <var>request</var> to a potentially trustworthy URL, if appropriate</a>.
 
- <li><p><a href="#https-upgrades-upgrade">Optionally, run HTTPS upgrading algorithm on <var>request</var>, if appropriate</a>.
+ <li><p>Optionally, run <a>upgrade an HTTP request</a> algorithm on <var>request</var>, if appropriate</a>.
 
  <li><p><a>Upgrade a mixed content <var>request</var> to a potentially trustworthy URL, if appropriate</a>.
 
@@ -5310,6 +5298,8 @@ these steps:
   <a>CORS check</a>, as <var>request</var>'s <a for=request>client</a> and the service worker can
   have different embedder policies.
 
+ <li><p>Run <a>handle an HTTPS upgrade fallback</a> algorithm on <var>request</var>, if appropriate.</a>
+
  <li>
   <p>If <var>actualResponse</var>'s <a for=response>status</a> is a <a>redirect status</a>, then:
 
@@ -5344,8 +5334,6 @@ these steps:
     <!-- not resetting actualResponse since it's no longer used anyway -->
   </ol>
 
- <li><p><a href="#https-upgrades-fallback">Optionally, run HTTPS upgrading fallback algorithm, if appropriate.</a>
-
  <li><p>Return <var>response</var>. <span class=note>Typically <var>actualResponse</var>'s
  <a for=response>body</a>'s <a for=body>stream</a> is still being enqueued to after
  returning.</span>