-
Notifications
You must be signed in to change notification settings - Fork 331
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add more timing information about (interim) responses #1483
Conversation
@bdekoz, thoughts from the Mozilla side? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To confirm, all these times are only exposed for CORSTAO-same-origin resources?
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
Confirmed. |
dc4e6d9
to
e1bcace
Compare
Add 3 response times: - firstInterimResponseStart: the first 103 - responseHeadersEnd: All headers have been received - responseBodyStart: The body started streaming Closes #345 Depends on whatwg/fetch#1483
@annevk could you spare time to finish reviewing this? Thanks! |
Ping |
See w3c/resource-timing#345 Since early hints have landed, there are additional useful timestamps that are 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) - Final headers received (when the last header has been received and we're ready for the body) - First bytes of the body received The naming in whatwg#345 is not finalized yet, but it's clear that these are the 3 interesting timestamps. This PR exposes those for later use by resource timing.
Add 3 response times: - firstInterimResponseStart: the first 103 - responseHeadersEnd: All headers have been received - responseBodyStart: The body started streaming Closes #345 Depends on whatwg/fetch#1483
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
It wasn't discussed, it's perhaps my misunderstanding of how the process should look like. 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.
Will do
On it |
|
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:
|
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. |
* Add interim response times Add 3 response times: - firstInterimResponseStart: the first 103 - responseHeadersEnd: All headers have been received - responseBodyStart: The body started streaming Closes #345 Depends on whatwg/fetch#1483 * Remove unimplemented parts for now
See w3c/resource-timing#345
Since early hints have landed, there are additional useful timestamp
that's currently not exposed:
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.
ResourceTiming: firstInterimResponseStart should include 100 responses web-platform-tests/wpt#39881
(See WHATWG Working Mode: Changes for more details.)
Preview | Diff