fetch
fetch copied to clipboard
whatwg
Pass in response status to mark resource timing
These changes are to support addition of http response status code to Perfomance resource timing. Further details are available at https://github.com/w3c/resource-timing/pull/335
- [x] At least two implementers are interested (and none opposed):
- Chromium : https://chromestatus.com/feature/5163838794629120
- Firefox : https://github.com/mozilla/standards-positions/issues/665
- [ ] Tests are written and can be reviewed and commented upon at:
- https://chromium-review.googlesource.com/c/chromium/src/+/3754923
- [ ] Implementation bugs are filed:
- Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=1343293
- Firefox: …
- Safari: …
- Deno (not for CORS changes): …
(See WHATWG Working Mode: Changes for more details.)
A rough sketch of using existing infrastructure:
-
navigate an iframe defines
reportFrameTiming. It needs to also take in a "has cross origin redirects" boolean and pass it to Fetch's report timing steps- We need to fix up the frame reporting so that it passes an algorithm that works with the current report timing steps
- The passed algorithm would need to nullify the status code in case of a non-same-origin iframe or one that has cross-origin redirects.
- In order for that to happen, we'd need to pass "has cross origin redirects" to process response end of body
@abinpaul1 @annevk - does this make sense?
Kinda, but then "has cross-origin redirects" needs to be state that Fetch maintains, I suspect. I'm also confused by "navigate an iframe" as I suspect some of those steps also need to apply to embed and object and processing the final response doesn't just result in a report but also needs to actually render something and such.
- The information regarding if there were any cross origin redirects can be determined if needed in fetch, but currently its stored in the has cross-origin redirects boolean on navigation params struct in HTML.
- I could see this boolean is used mainly in two places ([1], [2]). In both these places we also have access to the response as navigation param's response.
- Is it possible to consider moving the has cross-origin redirects boolean as a field to the response? Its value could be determined in the Fetch spec and it could be used as needed in the above two places as well and for our use case as well. This would maybe help us to easily reuse the boolean without having to pass it along to different algorithms.
@annevk @yoavweiss
Yeah that seems reasonable. And since we copy request's URL list over to the eventual response we might be able to reuse part of https://fetch.spec.whatwg.org/#concept-request-tainted-origin somehow.
(Apologies for taking so long. In the future please bug me on Matrix if I'm not responsive. Or ask the design question there as others might be able to answer as well.)
Have added the has-cross-origin-redirects boolean to the response. I'll also modify html spec to reuse this in place of has cross-origin redirects boolean on navigation params. Building html spec seems to be failing since it can't reference this new boolean.
In HTML you have to explicitly add the reference (search for data-x-href). If you cannot figure it out please PR what you do have and ask for help. Should not be too hard to get it all working. (Also, if it was not HTML it would be somewhat expected that CI fails and we just have to land things carefully with some delay so there's time for indexing the new terms.)
@annevk Thanks for the pointer. I've opened the HTML PR with the changes. https://github.com/whatwg/html/pull/8405
@abinpaul1 can you file bugs on Gecko and WebKit? That's the last thing remaining here.