Intent to Prototype: BYOB support for Fetch

213 views
Skip to first unread message

Nidhi Jaju

unread,
Apr 17, 2023, 3:03:11 AM4/17/23
to blink-dev, Adam Rice

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 desktop115
Shipping on Android115
Shipping on WebView115


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5192003450568704
Reply all
Reply to author
Forward
0 new messages