Web-Platform-Tests: resource-timing nextHopProtocol-tao-protected.https.html failure
Categories
(Core :: Performance, defect)
Tracking
()
| Performance Impact | none |
People
(Reporter: nic, Unassigned)
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.102 Safari/537.36
Steps to reproduce:
From a triage[1] of currently failing WPT resource-timing tests[2], the following Firefox test failures may (or may not be) be related to TAO:
[1] https://github.com/w3c/resource-timing/issues/233
[2] https://wpt.fyi/results/resource-timing?label=master&label=experimental&aligned
Actual results:
Test failure
Expected results:
Test pass
|
||
Comment 1•4 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
|
||
Updated•4 years ago
|
|
|
||
Comment 2•3 years ago
|
||
This test doesn't exist anymore.
|
Reporter | |
Comment 3•3 years ago
|
||
This was renamed to nextHopProtocol-is-tao-protected.https.html in this PR:
https://github.com/web-platform-tests/wpt/pull/28824
I still see a failure in FF here:
https://wpt.fyi/results/resource-timing/nextHopProtocol-is-tao-protected.https.html?label=master&label=experimental&aligned
https://wpt.live/resource-timing/nextHopProtocol-is-tao-protected.https.html
|
|
Reporter | |
Comment 4•2 years ago
|
||
Re-opening per the comment above
Howdy!
Just a heads-up from your friendly neighbourhood Chromies: https://github.com/web-platform-tests/wpt/pull/32241 is a thing.
It's part of a Chrome change where we want to remove a special case for deciding when to expose nextHopProtocol. Previously, if the resource wasn't for a "document destination" (iframes and the like), we'd expose cross-origin nextHopProtocol attributes regardless of how the Timing-Allow-Origin check went. Probably not what we want :)
The details are in the Fetch spec1, but the old special case does not conform to the spec. Not sure exactly when/how it changed in the spec but not having a special case was an intentional goal here.
Changing this behaviour does affect what scripts will see in the wild, though, so I wanted to signal-boost this and see if there are any concerns from the FF side. Since this is a bug fix to align with the spec, we figured the whole intent-to-ship process wouldn't strictly be needed but we'd love to hear any feedback! I'll cc myself to this bug but also feel free to jump in on the Chrome Platform Status entry2.
Cheers,
- Tom
Here's a small test to see whether cross-origin nextHopProtcol attributes are exposed regardless of TAO.
Right now, FF, Chrome and WebKit all expose the attribute but we shouldn't :(
<!doctype html>
<html>
<head>
</head>
<body>
<div>
Without a Timing-Allow-Origin header, we expect the empty string. We got '<span id="nhp">pending</span>'
<p>
Timing-Allow-Origin: <span id="tao">pending</span>
</div>
<script>
const cross_origin_url = "https://example.com/";
new PerformanceObserver(entryList => {
entryList.getEntries().forEach(entry => {
if (entry.name == cross_origin_url) {
nhp.textContent = entry.nextHopProtocol;
}
console.log(`entry.name: ${entry.name}`);
})
}).observe({"type": "resource", "buffered": true});
// Get a cross-origin resource
fetch(cross_origin_url, {"mode": "no-cors"}).then(r => {
let header_value = r.headers.get("Timing-Allow-Origin");
if (header_value == null) {
header_value = "--not set--";
} else {
header_value = "'" + header_value + "'";
}
tao.textContent = header_value;
}).catch(e => {
console.log("fetch failed:", e);
});
</script>
</body>
</html>
|
||
Updated•2 years ago
|
|
|
||
Comment 8•2 years ago
|
||
This test is now passing with the fix in bug 1768583.
Description
•