consider adding a note that response body may be re-buffered in browser

[wanderview]

When a response is passed to respondWith() most (all?) browsers will end up serializing the body through some kind of data pipe with a fixed capacity. This means that a response constructed with a ReadableStream body may see the data chunks get re-buffered into different size chunks on the other side. It would be nice if the spec captured this in some way. Perhaps as a note if it can't really be represented in normative text.

Not sure if this should be here or in fetch. cc @annevk

[wanderview]

For context, we got a bug from someone expecting that readablestream chunks would pass through in their original form:

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

[annevk]

When I wrote a comment in whatwg/fetch#267 (comment) in response to @ricea I did not expect it to already be a problem. 😊

I agree we should define this better. Ideally we'd also tackle the magic thread-boundary crossing at the same time.

cc @yutakahirano

(I think at least part of it should be here as the service worker needs to start this, but the infrastructure for it can be defined in Fetch and shared with the request side perhaps.)

[Banou26]

Hey there,
I am the reporter for https://bugs.chromium.org/p/chromium/issues/detail?id=1188114

I was wondering if Transferable Streams (chrome support) could allow service workers to pass data directly to the target frame without getting re-buffered with a fixed size.

Passing a stream from a service worker to a webpage via transferable streams(using postMessage) actually do work as expected and send the entire, full sized buffer (in my test case, Uint8Array(1000000)).

So since the tech is already there(at least for chrome), i was wondering if it'd just be possible to use it for fetch's respondWith and get the correct behavior.