Contact emailsnidhij...@chromium.org ExplainerNone
Specificationhttps://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 componentBlink>Network>FetchAPI <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ENetwork%3EFetchAPI> Motivation Using readable byte streams for Response.body allows more precise memory allocation, minimizes buffer copies, and reduces GC overhead. Initial public proposalNone TAG reviewNone TAG review statusNot 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 <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> ?Yes https://wpt.fyi/results/fetch/api/response/response-consume-stream.any.html?label=experimental&label=master&aligned Flag nameReadableStreamTeeCloneForBranch2 and FetchBYOB Requires code in //chrome?False Tracking bughttps://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 -- 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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMZNYAPyZ-TJsC5%3DtgYp_hBbrQtaspep2HRmDyLX7tJQFNGp%3Dw%40mail.gmail.com.
