Re: [whatwg/fetch] How response bodies get from a service worker to the main page is not very clear (#330)

> That means a script author will lose the access to the buffer wrapped by the Uint8Array object passed to controller.enqueue. Is it desirable?

I think that's fine. Once you have enqueued a buffer, the consumer is allowed to read it and modify it arbitrarily (including transfering and detaching it). In this case the consumer is the UA.

> We (Chrome) serialize the buffers to a C++ byte array and create Uint8Array objects from the byte array in the page. That means buffer's boundary is not preserved (i.e., buffers may be merged / split). As an implementer I would like the spec to allow us doing it.

This is an important point. I think that fits easily into the framework I outlined above. We just need to be a bit careful how things are specced. Instead of directly reading and enqueuing chunks as objects, we need to add some wiggle room in that process. Read the chunk as a Uint8Array, detach it, and enqueue new Uint8Array objects that point to the same sequence of bytes in the same order.

> I agree we need to spec types. Can we do something in webidl like `ReadableStream<Uint8Array>` with defined semantics if it hits a different chunk type?

I am not sure how this would work. I guess my instinct is to first formalize the semantics and then see if any of them are boilerplatey enough that they could be taken care of by a Web IDL type / by bindings generators.

> I don't understand this one. Just because the outer ReadableStream is locked does not prevent the inner source from continuing to provide data, right?

If by "inner source" you mean "underlying source", that's under the control of the author, not the UA.

What I mainly meant here was that we couldn't just keep doing what the spec currently does, and pretend there's a single ReadableStream object which gets transferred around.

> I guess we can do this, but its likely just going to be a spec thing. I doubt we will ever represent actual browser images, stylesheets, etc as ReadableStreams. We're just going to consume them in c++. The only place it will actually happen this way is in an outer fetch() call that returns a Response.body.

Basically there are two options. We could create a parallel "conceptual stream" type, with all the appropriate operations (reading, enqueueing, etc.) and say that is what is in play most of the time. Then the `response.body` getter lazily initializes a real `ReadableStream`, and there's some procedure for coping the "conceptual stream" into the `ReadableStream` so that operating on the latter impacts the former and vice versa.

Or we could keep doing what the current spec does, and use a `ReadableStream` to represent the streaming body in all cases. We just need to be a bit more careful about how things work across realms and event loops.

The latter sounds better to me.

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/330#issuecomment-231438620