Add more timing information about (interim) responses

[noamr]

See w3c/resource-timing#345

Since early hints have landed, there are additional useful timestamp
that's currently not exposed:

• First interim response start (e.g. when we received a 103)
  as a different timestamp from the final response start
  (e.g. when we received the 200)

Note that w3c/resource-timing#345 also mentions two additional
timestamps, which would be added incrementally when tests are authored for them.

• At least two implementers are interested (and none opposed):
  • Chrome: yes
  • Firefox: positive
  • Safari: positive
• Tests are written and can be reviewed and commented upon at Resource Timing: Expose firstInterimResponseStart web-platform-tests/wpt#37984
  ResourceTiming: firstInterimResponseStart should include 100 responses web-platform-tests/wpt#39881
• Implementation bugs are filed:
  • Chrome: 1402089
  • Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1811291
  • Safari: Resource Timing: Add interim response timings WebKit/standards-positions#109
  • Deno (not for CORS changes): N/A

(See WHATWG Working Mode: Changes for more details.)

---

Preview | Diff

[noamr]

@bdekoz, thoughts from the Mozilla side?

[annevk]

To confirm, all these times are only exposed for CORSTAO-same-origin resources?

[noamr]

To confirm, all these times are only exposed for TAO-same-origin resources?

Confirmed.

[noamr]

@annevk could you spare time to finish reviewing this? Thanks!

[noamr]

@annevk could you spare time to finish reviewing this? Thanks!

Ping

[noamr]

@annevk could you spare time to finish reviewing this? Thanks!

Ping

Re-ping @annevk :)

[annevk]

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.

[noamr]

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?

It wasn't discussed, it's perhaps my misunderstanding of how the process should look like.
Right now it seems like other vendors are supportive of the whole thing, but no vendor is actively implementing anything but firstInterimResponseStart. This includes WPT coverage. Given that, I thought it would be the right thing to first merge firstInterimResponseStart and then merge the other ones when there is a first implementer that's also going to spend the time on authoring WPTs for responseHeadersEnd and responseBodyStart.

Isn't merging this gradually a good thing, on the side of caution? I'm open to following the process in any other way. Perhaps I should have brought it up for discussion.

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.

Will do

• Please add some tests where a non-103 1xx comes first. E.g., 1) 110 103 200, 2) 199 200.

On it

[noamr]

• Please add some tests where a non-103 1xx comes first. E.g., 1) 110 103 200, 2) 199 200.

web-platform-tests/wpt#39881

[annevk]

I didn't realize we only had tests for a single feature. I agree that we need coverage for all features we add to the specification.

I think my issues with how this went are:

1. I (and others) had put effort into reviewing all three features together. We'll now have to do that again at some future point for the remaining features.
2. Other vendors might have started planning and if so that would have been impacted.

[noamr]

I didn't realize we only had tests for a single feature. I agree that we need coverage for all features we add to the specification.

I think my issues with how this went are:

1. I (and others) had put effort into reviewing all three features together. We'll now have to do that again at some future point for the remaining features.
2. Other vendors might have started planning and if so that would have been impacted.

Understood, apologies for the miscommunication. I should have clarified this when I realized I was going to implement them piecemeal. It seemed originally that it would be a one-go sort of thing.

Of course we're still interested in the other 2 metrics, just didn't get around to them yet and the first one was urgent to some folks, so if other vendors are already planning on adding them we'd support it and would be happy for those WPTs.