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

How about only using chunked encoding when the developer explicitly provided the header as part of [`HeadersInit`](https://fetch.spec.whatwg.org/#typedefdef-headersinit)? 

I can imagine developers wanting to provide a stream as request bodies simply for ergonomic reasons, and one could start supporting streams as request bodies, without having to make a final decision on the underlying networking model, which probably will require additional flags or headers to be set/provided by developers based on their knowledge of the server their app will be talking to(and over what kind of network). 

For example, I think step 4.2 of https://fetch.spec.whatwg.org/#http-network-fetch could be dropped, instead relying on the dev to provide the header if needed. 

We could then rewrite https://fetch.spec.whatwg.org/#concept-request-transmit-body to look for the header, or whether http2 is enabled(or some other yet to be defined heuristic), and define what "transmit bs" at step 5.2.2 means in more detail(or leave that open for now). 

Worst case, if a stream has been provided as a body, but no "chunked" header set(or for other reasons you can't support chunked), then the UA could simply accumulate bytes in a buffer as they are read from the stream, and when the stream is done, transmit the buffer in one chunk as a "normal" request. 

FYI this what I [ended-up doing](https://github.com/servo/servo/pull/26906) in Servo to make `fetch/api/basic/request-upload.any.js` pass...

So essentially you get "streaming" up to the networking layer of the UA, where bytes will then accumulate in a buffer, and finally be sent in one chunk. One could say it sort of defeats the purpose of using a stream as a request body, but I'd say it's a pretty good start. 

-- 
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-643798803