Thanks for getting that Adoption gate reviewed, and thanks for this work to improve Interop! LGTM3.
On Wednesday, July 8, 2026 at 7:55:25 AM UTC-7 Daniel Bratell wrote: > LGTM2 > > /Daniel > On 2026-07-08 14:15, Yoav Weiss (@Shopify) wrote: > > Also, please request review (or n/a) from the adoption checkbox. > > On Wednesday, July 8, 2026 at 2:14:50 PM UTC+2 Yoav Weiss wrote: > >> LGTM1 >> >> On Wednesday, July 1, 2026 at 6:24:53 PM UTC+2 [email protected] >> wrote: >> >>> *Contact emails* >>> *[email protected]* >>> >>> *Specification* >>> *Fetch Standard: blob URL fetch algorithm* >>> <https://fetch.spec.whatwg.org/#scheme-fetch:~:text=If%20rangeValue%20is%20failure%2C%20then%20return%20a%20network%20error.> >>> >>> *Summary* >>> Blob URL requests made with Fetch or XMLHttpRequest now follow the Fetch >>> Standard when parsing Range headers. Invalid or unsupported Range headers >>> fail with a network error instead of returning the full blob response. This >>> improves interoperability with other browsers and makes Chromium pass the >>> corresponding Web Platform Tests. >>> >>> *Blink component* >>> *Blink>Network>FetchAPI* >>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ENetwork%3EFetchAPI%22> >>> >>> *Web Feature ID* >>> *fetch* <https://webstatus.dev/features/fetch> >>> >>> *Motivation* >>> Chromium currently does not fully follow the Fetch Standard for blob URL >>> requests with invalid `Range` headers. When range parsing fails, Chromium >>> falls back to serving the full blob with `200 OK`, whereas the Fetch >>> Standard requires the request to fail with a network error. >>> >>> This change aligns Chromium with the Fetch Standard and improves >>> interoperability for Fetch and XMLHttpRequest range handling. >>> It resolves 52 failing Web Platform Tests in total, including 26 failing >>> `fetch/range/` subtests [1] that are part of the Interop 2026 "Fetch, >>> Uploads and Ranges" focus area [2], along with 26 corresponding >>> XMLHttpRequest tests [3]. >>> >>> [1] *web-platform-tests dashboard : fetch Blob* >>> <https://wpt.fyi/results/fetch/range?label=master&label=experimental&aligned&view=subtest&q=label%3Ainterop-2026-fetch%20blob.any> >>> >>> [2]*web-platform-tests dashboard : Fetch upload and ranges Interop 2026* >>> <https://wpt.fyi/results/fetch?label=master&label=experimental&aligned&view=interop&q=label%3Ainterop-2026-fetch> >>> >>> [3] *web-platform-tests dashboard : xhr blob* >>> <https://wpt.fyi/results/xhr?label=master&label=experimental&aligned&q=%20blob-range.any> >>> >>> *Initial public proposal* >>> *No information provided* >>> >>> *TAG review* >>> N/A - no new API or platform design; this is a narrow conformance fix to >>> existing Fetch Standard behavior. >>> >>> *TAG review status* >>> Not applicable >>> >>> *Goals for experimentation* >>> None >>> >>> *Risks* >>> >>> *Interoperability and Compatibility* >>> Compatibility risk is expected to be low. This assessment is qualitative >>> rather than based on dedicated telemetry for the exact affected scenario. >>> The change affects only Fetch and XMLHttpRequest requests to blob: URLs >>> that include an invalid, malformed, or unsupported Range header. Requests >>> without a Range header are unchanged, valid single-range requests continue >>> to behave as before, and non-blob: URL requests are unaffected. >>> The previous Chromium behavior returned the full blob when Range parsing >>> failed. This change instead follows the Fetch Standard by treating such >>> requests as network errors. Firefox and Safari already implement this >>> behavior, so the change improves interoperability and aligns Chromium with >>> the web platform. >>> The primary compatibility risk is sites relying on Chromium's previous >>> fallback behavior for invalid Range headers on blob: URLs. We expect this >>> to be uncommon because it requires both issuing Range requests against >>> blob: URLs and using invalid or unsupported Range syntax. >>> >>> >>> >>> *Gecko: Shipped/Shipping, Firefox already implements this behavior and >>> passes the corresponding Web Platform Tests WebKit: >>> Shipped/Shipping, Safari already implements this behavior and passes the >>> corresponding Web Platform Tests.* >>> >>> *Web developers*: No signals >>> >>> *Other signals*: >>> >>> *Ergonomics* >>> No new API ergonomics risk. Existing Fetch/XHR usage is unchanged for >>> valid single Range headers; invalid values now fail as specified. >>> >>> *Activation* >>> No developer activation is required. The corrected behavior applies >>> automatically to blob URL requests with Range headers. >>> >>> *Security* >>> No new security risk. The change makes invalid blob URL Range headers >>> fail instead of serving a full blob response, which is stricter than >>> current behavior. >>> >>> *WebView application risks* >>> *Does this intent deprecate or change behavior of existing APIs, such >>> that it has potentially high risk for Android WebView-based applications?* >>> Low. The risk is no higher for Android WebView applications than for >>> websites. Only blob: URL requests with invalid, malformed, or unsupported >>> Range headers are affected; all other requests are unchanged. >>> >>> >>> *Debuggability* >>> Existing Fetch/XHR error handling applies. Invalid blob URL Range >>> requests surface as a network error / Fetch TypeError, and valid ranges >>> continue to produce 206 Partial Content. >>> >>> *Will this feature be supported on all six Blink platforms (Windows, >>> Mac, Linux, ChromeOS, Android, and Android WebView)?* >>> Yes >>> Applies to Chromium platforms that use the common blob URL loader for >>> Fetch/XHR, including desktop, Android, and Android WebView. >>> >>> *Is this feature fully tested by **web-platform-tests* >>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>> *?* >>> Yes >>> Covered by Web Platform Tests under fetch/range/, including >>> blob.any.html and blob.any.worker.html cases for invalid blob URL Range >>> headers. The CL also updates expectations for the corresponding XHR blob >>> range tests and adds Chromium unit coverage for Fetch-compatible single >>> Range parsing and BlobURLLoader invalid range handling. Relevant CL: >>> *https://chromium-review.googlesource.com/c/chromium/src/+/7902659* >>> <https://chromium-review.googlesource.com/c/chromium/src/+/7902659> >>> >>> *Flag name on about://flags* >>> *No information provided* >>> >>> *Finch feature name* >>> BlobURLFetchRangeHeaderValidation >>> >>> *Rollout plan* >>> Will ship enabled for all users >>> >>> *Requires code in //chrome?* >>> False >>> >>> *Tracking bug* >>> *https://issues.chromium.org/issues/510995915* >>> <https://issues.chromium.org/issues/510995915> >>> >>> *Measurement* >>> No dedicated UseCounter is planned. This is a narrow standards >>> conformance fix covered by WPT and Chromium unit tests; invalid blob URL >>> Range header usage is expected to be rare. >>> >>> *Availability expectation* >>> Available in Chromium-based browsers once the shipping milestone reaches >>> stable. >>> >>> *Adoption expectation* >>> No active developer adoption is expected because this is a standards >>> conformance fix to existing Fetch/XHR behavior, not a new API. Sites using >>> valid single Range headers continue to work. Sites using invalid blob URL >>> Range syntax may need to fix that syntax if they currently rely on Chromium >>> returning the full blob response. >>> >>> *Adoption plan* >>> No developer adoption plan is needed. The change ships as a browser >>> behavior fix and is validated by Web Platform Tests. Any affected sites >>> should update invalid blob URL Range header usage to use valid single Range >>> syntax. >>> >>> *Non-OSS dependencies* >>> No >>> >>> *Estimated milestones* >>> Shipping on desktop >>> 152 >>> Shipping on Android >>> 152 >>> Shipping on WebView >>> 152 >>> >>> *Anticipated spec changes* >>> None. This implements the current Fetch Standard behavior. >>> >>> *Link to entry on the Chrome Platform Status* >>> *https://chromestatus.com/feature/6237991531053056?gate=5496962989293568* >>> <https://chromestatus.com/feature/6237991531053056?gate=5496962989293568> >>> >>> This intent message was generated by *Chrome Platform Status* >>> <https://chromestatus.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 [email protected]. > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d8da604f-feba-4a0c-8982-7b56f48cbec2n%40chromium.org > > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d8da604f-feba-4a0c-8982-7b56f48cbec2n%40chromium.org?utm_medium=email&utm_source=footer> > . > > -- 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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/94a4e9a8-c8ea-4a71-80a4-92424d858dd0n%40chromium.org.
