Re: [whatwg/fetch] TAO check and child frame navigations (#1221)

Chrome implements the TAO check in two places:
https://source.chromium.org/chromium/chromium/src/+/master:services/network/cors/cors_url_loader.cc;l=666;drc=cc68781020815770d5e56cf555c858681ab6d002, which follows the fetch spec, as far as I can tell.

Then there's also https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/core/timing/performance.cc;l=451;drc=9bd90f9e5aa1524e928b4619e4574441b020d153. This sort of follows the fetch spec, but calculates response tainting its own way, and adapted to handle the reporting to parent case as well. This version operates on the saved redirect responses (for unfortunate reasons, there's actually another copy of this logic elsewhere, but it's supposed to be identical).

As for reporting to parent, I think Chrome attempts to only report it for the first HTTP load in a frame: https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/core/loader/document_loader.cc;l=944;drc=221e331b49dfefadbc6fa40b0c68e6f97606d0b3

I believe the theory is it's OK to report the initial load, because the src was presumably specified by the parent.

I'm not sure that the Chrome logic is 100% sound though:
- if Chrome loads a non-HTTP response, and then navigates to a HTTP response, it seems like it might incorrectly report the response timing
- if the page is navigated elsewhere before the first navigation completes, it seems like it might incorrectly report the response timing

But I'm not familiar with the background here, so my reasoning of why things are/aren't OK may very well be wrong.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/1221#issuecomment-827438151