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/433c9a2f-1aed-47e5-b7c0-76f5bd139ddbn%40chromium.org.
