Closed abinpaul1 closed 2 years ago
I suggest using responseStatus
instead of responseStatusCode
to better match Fetch's response.status
property name.
It would be good to get @mikewest & @annevk's eyes on this.
This is the kind of information that developers asked since quite a long time, if security and fetch people think that it is done in a way that doesn't enable security risks, then it looks like a valid addition, but iirc, previous attempts failed in the past.
The explainer suggests that "The status code is behind CORS check", which would alleviate my concerns. That's the same check we use for the status
and statusText
members of Response
objects through the Fetch API, and doesn't seem unreasonable to extend to timing APIs.
Yeah, as long as you don't go beyond the normal same-origin policy and its CORS extension in terms of information exposure it ought to be fine. (I vaguely recall prior attempts wanting to expose it all the time, which would be problematic.)
Hi @abinpaul1 , we had a discussion in today's TAG meeting and are generally happy with this proposal. Thanks @mikewest @annevk for helping with the review.
Wotcher TAG!
I'm requesting a TAG review of HTTP Status Code in Resource Timing.
Adds a field
responseStatusCode
to PerfomanceResourceTiming which holds an integer corresponding to HTTP status code returned when fetching the resource.Further details:
You should also know that...
We'd prefer the TAG provide feedback as :
💬 leave review feedback as a comment in this issue and @-notify @abinpaul1 @yoavweiss