Intent to Prototype: BYOB support for Fetch

[Nidhi Jaju]

Contact emails

nidh...@chromium.org

Explainer

None

Specification

https://fetch.spec.whatwg.org/#http-network-fetch

Summary

Makes Response.body be a readable byte stream instead of a "default" readable stream. This enables it to be used with bring-your-own-buffer (BYOB) readers, reducing garbage collection overhead and copies.

Blink component

Blink>Network>FetchAPI

Motivation

Using readable byte streams for Response.body allows more precise memory allocation, minimizes buffer copies, and reduces GC overhead.

Initial public proposal

None

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Low risk because streams and fetch have already been standardized for a long time. Other browsers have implemented other parts of the standard, and Firefox has already shipped this behavior for many months and others will most likely also adapt this feature as well soon.

Gecko: Shipped/Shipping (https://github.com/whatwg/fetch/issues/267#issuecomment-1350303670) Already shipped in Firefox in 2022.

WebKit: Positive (https://github.com/whatwg/fetch/pull/1593) @annevk from Apple approved the PR to update the spec with relevant changes and expressed interest as an implementer on behalf of Apple.

Web developers: No signals

Other signals: Deno is also interested in, and somewhat shipped, this behavior (https://github.com/denoland/deno/issues/17386).

Activation

Currently, to clone a body, we tee the body's stream, but teeing always returns two "default" streams, where the chunks are not cloned for both streams. Making Response.body into a byte stream, will mean that cloning it will result in cloning the chunks for the second stream, which is different behavior. In order to mitigate activation risks, we are splitting this change into two releases. One where the default teeing behavior will also start to clone for the second stream behind the "ReadableStreamTeeCloneForBranch2" feature flag, and then make Response.body a readable byte stream behind the "FetchBYOB" feature flag.

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?

Debuggability

No special support needed.

Is this feature fully tested by web-platform-tests?

Yes
https://wpt.fyi/results/fetch/api/response/response-consume-stream.any.html?label=experimental&label=master&aligned

Flag name

ReadableStreamTeeCloneForBranch2 and FetchBYOB

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1243329

Estimated milestones

Shipping on desktop

115

Shipping on Android

115

Shipping on WebView

115

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5192003450568704