[blink-dev] Intent to Ship: Fetch-compliant range handling for blob URLs

[Jatin Mittal]

Contact emails

Jatin...@microsoft.com

 

Specification

Fetch Standard: blob URL fetch algorithm

 

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

 

Web Feature ID

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

[2]web-platform-tests dashboard : Fetch upload and ranges Interop 2026

[3] web-platform-tests dashboard : xhr blob

 

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?

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

 

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

 

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

 

This intent message was generated by Chrome Platform Status.