Re: [whatwg/fetch] Update HTTPFetch algorithm to support new SW Handle Fetch returns (PR #1832)

@yoshisatoyanagisawa commented on this pull request.



>  
-    <ol>
-     <li><p>Set <var>fetchParams</var>'s <a for="fetch params">timing info</a>'s
-     <a for="fetch timing info">final service worker start time</a> to
-     <var>serviceWorkerStartTime</var>.
+    <p>If <var>fetchResponse</var> is non-null, then:
+     <ol>
+     <li><p>If<var>fetchResponse</var> is <a for=/>response</a>, then:
+      <ol>
+       <li><p>Set <var>response</var> to <var>fetchResponse</var>.
+       <li><p>Set <var>fetchParams</var>'s <a for="fetch params">timing info</a>'s
+       <a for="fetch timing info">final service worker start time</a> to
+       <var>serviceWorkerStartTime</var>.
+       <li><p>Set <var>fetchParams</var>'s <a for="fetch params">timing info</a>'s

Thanks for the link.
And yes, [fetch response handover](https://fetch.spec.whatwg.org/#fetch-finale), which is called inside [Main fetch](https://fetch.spec.whatwg.org/#main-fetch), seems to set `timingInfo` which is set to be `fetchParam`'s `timing info` in Step 1.  The `timingInfo` gets eventually be used in Step 4.2.8.
Then, I understand we cannot avoid updating `timing info` in `fetchParam`.

Then, stepping back and think why we made a `response` to have `timing info`.  My understanding is that Output of an algorithm can usually be one or none.  Therefore, we need to choose either returning a tuple of response and `timing info`, or piggyback the current `response`.  We chose latter.  I think either to choose is up to the fetch editor and an author

Then, this PR sounds good to me.

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

Message ID: <whatwg/fetch/pull/1832/review/3514333520@github.com>