Re: [whatwg/fetch] Add HTTP fetch step on 421. (#1141)

@annevk commented on this pull request.

Indentation could use some cleanup, but otherwise this looks good to me.

> +
+     <li><p>If <var>aborted</var> is set, then return an <a>aborted network error</a>.
+
+     <li><p>Return a <a>network error</a>.
+    </ol>
+
+   <li>
+    <p>If <var>actualResponse</var>'s <a for=response>status</a> is 421,
+     <var>request</var>'s <a for=request>body</a> is non-null, and
+     <var>request</var>'s <a for=request>body</a>'s <a for=body>source</a> is
+      null, then return a <a>network error</a>.
+
+   <li><p>Set <var>response</var> to the result of performing an <a>HTTP-network-or-cache fetch</a>
+   using <var>request</var> on a new <a lt=connection>connection</a>.
+
+    <p class=XXX>User agents should have an <a>implementation-defined</a> recursion limit.

This should be a normal paragraph, not an open issue.

> @@ -4593,6 +4593,31 @@ Range Requests</cite>. [[HTTP-RANGE]] However, this is not widely supported by b
    using <var>request</var>.
   </ol>
 
+ <li>
+  <p>If <var>response</var>'s <a for=response>status</a> is 421, then:
+
+  <ol>
+   <li>
+    <p>If the ongoing fetch is <a for=fetch>terminated</a>, then:
+
+    <ol>
+     <li><p>Let <var>aborted</var> be the termination's aborted flag.
+
+     <li><p>If <var>aborted</var> is set, then return an <a>aborted network error</a>.
+
+     <li><p>Return a <a>network error</a>.

This could happen during the fetch initiated below if the initial fetch (that resulted in a 421) was explicitly aborted somehow. It seems safer to error in that case so aborting doesn't result in new information, but I'm not sure it matters a whole lot. I think I'd prefer keeping this as-is and revisiting if there are deployment issues. Note that implementations can still show the relevant information in DevTools and such.

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

Received on Monday, 1 February 2021 07:13:36 UTC