Review request for HTTP Status Code in Resource Timing

[abinpaul1]

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.

• Explainer: https://github.com/abinpaul1/resource-timing/blob/explainer-resource-response-status/Explainers/Response_Status_Code.md
• Specification URL: Add response status code to PerfomanceResourceTiming w3c/resource-timing#335
• Tests: Add response status code to Resource Timing web-platform-tests/wpt#34828
• User research: None
• Security and Privacy self-review: https://github.com/abinpaul1/resource-timing/blob/explainer-resource-response-status/Explainers/Response_Status_Code.md#self-review-questionnaire-security-and-privacy
• Primary contacts (and their relationship to the specification):
  • Abin K Paul (@abinpaul1), spec author
  • Yoav Weiss (@yoavweiss), Google, spec mentor
• Organization(s)/project(s) driving the specification: Google
• Key pieces of existing multi-stakeholder review or discussion of this specification:
  • Discussion thread: Add response status codes for resources in Resource Timing API. w3c/resource-timing#90
• External status/issue trackers for this specification: https://chromestatus.com/feature/5163838794629120

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• Relevant time constraints or deadlines: September 1, 2022
• The group where the work on this specification is currently being done: W3C Web Performance WG
• Major unresolved issues with or opposition to this specification: None
• This work is being funded by: Google

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

[domenic]

I suggest using responseStatus instead of responseStatusCode to better match Fetch's response.status property name.

[hober]

It would be good to get @mikewest & @annevk's eyes on this.

[ylafon]

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.

[mikewest]

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.

[annevk]

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.)

[maxpassion]

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.