Thank you, Mike and Yoav! I filed a standards position request with WebKit, and they are supportive as well: https://github.com/WebKit/standards-positions/issues/194.
On Wed, May 31, 2023 at 9:33 PM Yoav Weiss <yoavwe...@chromium.org> wrote: > Thanks for aligning with Firefox here! > > On Fri, May 26, 2023 at 5:32 AM Nidhi Jaju <nidhij...@chromium.org> wrote: > >> 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. >> >> As mentioned in the Activation section below, we plan to ship the >> ReadableStreamTeeCloneForBranch2 feature first, and then the FetchBYOB >> feature later. >> Blink componentBlink>Network>FetchAPI >> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ENetwork%3EFetchAPI> >> >> 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. >> > > Can you help me understand what potential breakage (if any) may look like? > How would these 2 behavior changes break developer expectations? What > would code that breaks as a result of this look like? > The 2 changes are incremental, and will only break developer expectations if there are websites that rely on the output of cloning a request/response to have the same chunks as before or rely on modifying one of the chunks changing the other one. A code sample of where the behavior difference would be observable is: const request = new Request("image.jpg"); fetch(request).then((response) => { const cloned_response = response.clone(); const { value: value1 } = await response.getReader().read(); const { value: value2 } = await cloned_response.getReader().read(); if (value1 === value2) { console.log('old behavior'); } else { console.log('new behavior'); } }); In both the old and the new behaviour, the contents of the Uint8Array are the same, so it only makes a practical difference if a script modifies the output. (An explainer that outlined that would've been helpful, but inline > explanations are fine as well) > > >> >> >> 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. >> >> >> Will this feature be supported on all six Blink platforms (Windows, Mac, >> Linux, Chrome OS, Android, and Android WebView)?Yes >> >> This feature will be purely implemented in Blink and so cross-platform >> support is automatic. >> >> >> Is this feature fully tested by web-platform-tests >> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >> ?Yes >> >> 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 116 >> Shipping on Android 116 >> Shipping on WebView 116 >> >> Anticipated spec changes >> >> Open questions about a feature may be a source of future web compat or >> interop issues. Please list open issues (e.g. links to known github issues >> in the project for the feature specification) whose resolution may >> introduce web compat/interop risk (e.g., changing to naming or structure of >> the API in a non-backward-compatible way). >> None. The spec change for BYOB support for Fetch was already landed at >> https://github.com/whatwg/fetch/pull/1593. >> >> Link to entry on the Chrome Platform Status >> https://chromestatus.com/feature/5192003450568704 >> >> Links to previous Intent discussionsIntent to prototype: >> https://groups.google.com/a/chromium.org/g/blink-dev/c/Iyt6Ca9PiJQ/m/s_D7A0YwCgAJ >> >> -- >> 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/CAMZNYANt%2BwCoAYOfh1Bj7EJrdTz3jkd%3D%3DAyeBv9f8P2Ccu1wkg%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMZNYANt%2BwCoAYOfh1Bj7EJrdTz3jkd%3D%3DAyeBv9f8P2Ccu1wkg%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . > > -- 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/CAMZNYAMyLsv2_i3Efh3FkTXFcp-U6f56hvXc2EyEqu3gUq7Gug%40mail.gmail.com.
