Intent to Implement and Ship: Reading Blob URL for invalid/nonexistent Blob should end with a network error
Marijn Kruisselbrink
Contact emails
Explainer/spec
https://fetch.spec.whatwg.org/#scheme-fetch (and https://url.spec.whatwg.org/#url-parsing which sets the URL's object scheme-fetch then looks up).
Summary
Currently our implementation returns a 404 when attempting to read from a invalid/non-existing Blob URL. The spec however says this should instead result in a network error.
Motivation
Other browsers do correctly return a network error, so this make use more compatible.
Risks
Interoperability and Compatibility
Other browser already implement the correct behavior (i.e. all of edge, firefox and safari pass the various subtests of https://wpt.fyi/FileAPI/url/url-with-xhr.any.worker.html that chrome fails because it returns a 404).
Also even in chrome, the fetch() API already translates 404's in Blob URLs to network errors, so this would also help make chrome more consistent with itself. As such I think the script visible effect should be mostly limited to usage of XHR, where failing to load a blob URL will behave differently after this change.
Edge: Shipped
Firefox: Shipped
Safari: Shipped
Web developers: Unknown
Debuggability
If anything this will make debuggability less confusing (i.e. currently DevTools will show a 404 for an invalid blob URL even if the URL was fetched through the fetch API, which as mentioned above translates these 404's to network errors anyway).
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
Is this feature fully tested by web-platform-tests?
Yes, various tests in https://wpt.fyi/FileAPI/url test this behavior for both the fetch and XHR APIs. I don't think there should be any difference in how other APIs tread invalid blob URLs, since either way the URL will still fail to load.
Link to entry on the feature dashboard
https://www.chromestatus.com/feature/5689937680662528
Requesting approval to ship?
Yes
Chris Harrelson
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BOSsVYwYRAFkhk%3Dbt9%3DxUQE4XRVxrWvEqPAaZHK-dOGsedy0A%40mail.gmail.com.
Mike West
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw93P5FDJzDK_QrYYaarWF_ouv9FN0CyrLzviZur3eHOHw%40mail.gmail.com.
Daniel Bratell
-mike
LGTM1
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BOSsVYwYRAFkhk%3Dbt9%3DxUQE4XRVxrWvEqPAaZHK-dOGsedy0A%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw93P5FDJzDK_QrYYaarWF_ouv9FN0CyrLzviZur3eHOHw%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DfFfN2taRe-c5UEk-Z1gWpp9WheWqZZvEoisFhsJWOiDA%40mail.gmail.com.