Re: [whatwg/fetch] Add more timing information about (interim) responses (PR #1483)

@annevk commented on this pull request.

Thanks for pushing this @noamr! One nit and tests remain and a bit of process feedback for next time.

I find it rather odd that the scope of this PR has been reduced based on what Chromium deemed worthy to implement right now. Especially without signals from other stakeholders that that seems reasonable. But perhaps this was discussed somewhere?

Either way, given the relatively small scope of this feature I'm okay with it, but OP will need updating.

As for tests:

* Next time please land them as `.tentative` until specifications PRs land/are about to land.
* Please add some tests where a non-103 1xx comes first. E.g., 1) 110 103 200, 2) 199 200.

> @@ -5744,6 +5751,14 @@ optional boolean <var>forceNewConnection</var> (default false), run these steps:
          <li><p>If <var>request</var>'s <a for=request>mode</a> is "<code>websocket</code>" and
          <var>status</var> is 101, then <a for=iteration>break</a>.
 
+         <li><p>If <var>timingInfo</var>'s
+         <a for="fetch timing info">first interim network-response start time</a> is 0, then set
+         <var>timingInfo</var>'s
+         <a for="fetch timing info">first interim network-response start time</a> to
+         <var>timingInfo</var>'s <a for="fetch timing info">final network-response start time</a>.

I was thinking about this again and how eventually for "`websocket`" we might want to implement the prior step using a shared interim response callback. Based on that I think this step should come first here. It shouldn't have any normative impact, but it will make refactoring seem more straightforward.

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

Message ID: <whatwg/fetch/pull/1483/review/1414420641@github.com>