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]* <[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.
