Re: [whatwg/fetch] Request body streams should use chunked encoding (#966)

> I need the streaming, because I'm actually streaming live audio. I need the audio to be processed immediately, before the end of the stream. That's the whole reason why I need this.

Ok, so in that case I assume you also know exactly what the server expects, and you would be able to either set the "chunked" encoding header, or some other flag that would be provided by the Fetch API, to "tell" the UA what underlying networking model to use(and if not supported, the UA could immediately terminate the fetch)? 

What I'm saying is that, if I were to try to sum-up the discussion so far, it would be "it's complicated". And I think one reason for this is the attempt to tie using a `ReadableStream` as a request body with a specific networking model. 

I'm instead arguing the API can be supported, with a worst-case implementation involving simply buffering the bytes as they are read from the stream, and further flag/headers can be defined by Fetch and used by users who "need" a certain networking model, to modulate what step 5.2.2 of https://fetch.spec.whatwg.org/#concept-request-transmit-body exactly does. 

For example step 5.2.2 could switch on certain headers being present, or certain flags set, and then "transmit" bytes over the network according to certain networking models. Let's say similarly to how [extract init body](https://fetch.spec.whatwg.org/#concept-bodyinit-extract) switches based on the type of the object. This approach would be extensible I think, since the switch statement could be extended as new networking models are supported. 

-- 
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/966#issuecomment-643889853