Design Review #757

#757: Review request for HTTP Status Code in Resource Timing

Opened Jul 13, 2022

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: https://github.com/w3c/resource-timing/pull/335
Tests: https://github.com/web-platform-tests/wpt/pull/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: https://github.com/w3c/resource-timing/issues/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

Discussions

Discussed Jul 1, 2022 (See Github)

Yves wonders how this fits in with Fetch's hiding of this information

[Tess & Yves read explainer & related docs]

Yves: this allows you to distinguish between a CORS check failure and some other server-side failure

... for things not using CORS (images etc.), you can kind of figure this out, coarsely, by detecting if the resource was loaded

... would be nice to have mike west's read on this, or anne's. it opens the can of worms of differentating errors

[Tess & Yves each leave comments on the issue]

Comment by @domenic Jul 13, 2022 (See Github)

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

Comment by @hober Jul 26, 2022 (See Github)

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

Comment by @ylafon Jul 26, 2022 (See Github)

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.

Comment by @mikewest Jul 26, 2022 (See Github)

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.

Comment by @annevk Jul 28, 2022 (See Github)

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

Discussed Aug 1, 2022 (See Github)

Max: I think this is resolved

Yves: I think we can close, positive feedback

agree to close

Comment by @maxpassion Aug 31, 2022 (See Github)

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.