Reinvestigate redirects to data URLs

[annevk]

I managed to flip on this several times in the course of #111, the last time due to investigations in how navigate works in #309. I think my mistake might have been that I did not investigate "no-cors", as redirects to data URLs still work there in (some) implementations and lead to the response being treated as CORS-cross-origin (HTML's term).

Related tests that might need updating:

• Redirects to non-HTTP(S) schemes are a network error web-platform-tests/wpt#3095
• Adding data URL loading after redirections web-platform-tests/wpt#3644

Thanks to @youennf for finding this.

[annevk]

Also copying @bzbarsky @mikewest due to recent data URL changes in Fetch and HTML they were involved in.

Would any redirect to a data URL make it qualify as being CORS-cross-origin, or only if the redirect was found on another origin?

[bzbarsky]

Would any redirect to a data URL make it qualify as being CORS-cross-origin

I think in Gecko any redirect to a data URL is considered CORS-cross-origin.

[annevk]

Chrome does seem to consistently fail for redirects to data URLs. E.g., adding

<script src=../resources/redirect.py?location=data:,alert(1) onerror=alert('error')></script>

to fetch/api/redirect/redirect-schemes.html in web-platform-tests alerts "error", whereas Firefox and Safari alert "1".

Not sure what we want to align on here.

Firefox is the only browser to follow redirects to data URLs consistently by failing several of the tests in fetch/api/redirect/redirect-to-dataurl.html. It seems that other browsers have special cases for fetch() which would end up showing if you used a service worker.

[annevk]

I also tested with

<img src="../resources/redirect.py?location=data:image/png%3Bbase64,iVBORw0KGgoAAAANSUhEUgAAAIUAAABqCAIAAAAdqgU8AAAAAXNSR0IArs4c6QAAAARnQU1BAACxjwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAAF6SURBVHhe7dNBDQAADIPA%2Bje92eBxSQUQSLedlQzo0TLQonFWPVoGWjT%2BoUfLQIvGP/RoGWjR%2BIceLQMtGv/Qo2WgReMferQMtGj8Q4%2BWgRaNf%2BjRMtCi8Q89WgZaNP6hR8tAi8Y/9GgZaNH4hx4tAy0a/9CjZaBF4x96tAy0aPxDj5aBFo1/6NEy0KLxDz1aBlo0/qFHy0CLxj/0aBlo0fiHHi0DLRr/0KNloEXjH3q0DLRo/EOPloEWjX/o0TLQovEPPVoGWjT%2BoUfLQIvGP/RoGWjR%2BIceLQMtGv/Qo2WgReMferQMtGj8Q4%2BWgRaNf%2BjRMtCi8Q89WgZaNP6hR8tAi8Y/9GgZaNH4hx4tAy0a/9CjZaBF4x96tAy0aPxDj5aBFo1/6NEy0KLxDz1aBlo0/qFHy0CLxj/0aBlo0fiHHi0DLRr/0KNloEXjH3q0DLRo/EOPloEWjX/o0TLQovEPPVoGWjT%2BoUfLQIvGP/RoGWjR%2BIceJQMPIOzeGc0PIDEAAAAASUVORK5CYII" alt=oops>

which gave identical results.

[toyoshim]

I reached this thread during a bug triage for the Chrome Loading team.

At this moment, we don't focus on this topic, but if there is an update on this thread, please contact us via the following entry.
https://bugs.chromium.org/p/chromium/issues/detail?id=527326

[annevk]

I finally created a PR for the demos above at web-platform-tests/wpt#27463. @youennf I'm inclined to uphold the current standard and not allow redirects to data: URLs as far as the fetch algorithm is concerned. They are still supposed to work for navigations as those handle redirects on their own.

[annevk]

Bugs:

• https://bugs.webkit.org/show_bug.cgi?id=221597
• https://bugzilla.mozilla.org/show_bug.cgi?id=1691658

I also closed the Chrome bug.