Re: [whatwg/fetch] Process 103 Early Hints response (PR #1404)

@bashi commented on this pull request.



> +
+       <li><p>If <var>responseStartTime</var> is null, set <var>responseStartTime</var> to
+       <a for=/>coarsened shared current time</a> given <var>fetchParams</var>'s
+       <a for="fetch params">cross-origin isolated capability</a>, immediately after the user
+       agent's HTTP parser receives the first byte of the response (e.g., frame header bytes for
+       HTTP/2 or response status line for HTTP/1.x).
+
+       <li><p>Let <var>status</var> be <a for=response>status</a> of <a for=/>response</a>.
+
+       <li><p>If <var>status</var> is in the range 100 to 199, inclusive:
+        <ol>
+         <li><p>If <var>status</var> is 101, <a for=iteration>break</a>.
+
+         <li><p>If <var>status</var> is 103, then:
+          <ol>
+           <li><p>If <var>fetchParams</var>'s <a for="fetch params">process early hints response</a>

I see. Updated the node.

> @@ -5460,22 +5467,55 @@ optional boolean <var>forceNewConnection</var> (default false), run these steps:
        <a for=request>body</a> cannot be recreated and that is why the buffer is needed.
       </div>
 
-     <li><p>Set <var>timingInfo</var>'s
-     <a for="fetch timing info">final network-response start time</a> to the
-     <a for=/>coarsened shared current time</a> given <var>fetchParams</var>'s
-     <a for="fetch params">cross-origin isolated capability</a>, immediately after the user agent's
-     HTTP parser receives the first byte of the response (e.g., frame header bytes for HTTP/2 or
-     response status line for HTTP/1.x).
-
-     <li><p>Wait until all the <a for=/>headers</a> are transmitted.
+     <li><p>Let <var>responseStartTime</var> be null.

I think we can check the field instead of adding the variable. Done.

> +
+         <li><p>If <var>status</var> is 103, then:
+          <ol>
+           <li><p>If <var>fetchParams</var>'s <a for="fetch params">process early hints response</a>
+           is non-null, then:
+           <ol>
+            <li><p><a for=/>Assert</a>: <var>request</var>'s <a for=request>mode</a> is
+            "<code>navigate</code>".
+
+            <p class="note nobackref">The following step might trigger other fetches. The assertion
+            is to avoid potential CORS breakage.
+
+            <li><p><a>Queue a fetch task</a> to run <var>fetchParams</var>'s
+            <a for="fetch params">process early hints response</a>, with <a for=/>headers</a>.
+           </ol>
+           <li><p><a for=iteration>Continue</a>.

Done.

>  
-      <p class="note no-backref">These kind of <a for=/>responses</a> are eventually followed by a
-      "final" <a for=/>response</a>.
+       <li><p>Let <var>status</var> be <a for=response>status</a> of <a for=/>response</a>.
+
+       <li><p>If <var>status</var> is in the range 100 to 199, inclusive:
+        <ol>
+         <li><p>If <var>status</var> is 101, <a for=iteration>break</a>.
+
+         <li><p>If <var>status</var> is 103, then:

Done.

>  
      <li>
-      <p>Any <a for=/>responses</a> whose <a for=response>status</a> is in the range 100 to 199,
-      inclusive, and is not 101, are to be ignored, except for the purposes of setting
-      <var>timingInfo</var>'s <a for="fetch timing info">final network-response start time</a> above.
+      <p>While true:
+      <ol>
+       <li><p>Wait until all the <a for=/>headers</a> are transmitted.

Nice catch. Moved setting the timing info field at the top of the while loop. I think this preserves the current behavior.

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

Message ID: <whatwg/fetch/pull/1404/review/899900982@github.com>