On Monday, June 5, 2023 at 1:13:11 PM UTC+2 Nidhi Jaju wrote:

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.


That's great!!
 


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.


Do we have a sense of an upper bound on potential breakage? e.g. a use 
counter for fetch response cloning?
 


(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


I'm failing to find the FetchBYOB flag. Has it landed?
 



Requires code in //chrome?False

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

Estimated milestonesShipping on desktop116Shipping on Android116Shipping on 
WebView116

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 Statushttps://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/bd63077a-f638-4836-86ab-3724cb375e11n%40chromium.org.

Reply via email to