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

The below describes the heuristic used by Hyper(Rust HTTP libary) which seems pretty good, and I think it actually sort of matches the current wording spec:

> If the body's `size_hint` method does not return an exact size, the hyper will check if you've included a specific header to describe the body. If that doesn't exist either, hyper will resort to a streaming body, which over HTTP/1.1, will use chunked transfer-encoding. It _should_ automatically add the header. (source: https://github.com/hyperium/hyper/issues/2232#issuecomment-644322104)

On thing worth noting is fetch sets the "content-length" header at step 5.6 of #http-network-or-cache-fetch only if [total-bytes](https://fetch.spec.whatwg.org/#concept-body-total-bytes) is set, and that seems to only be set at step 39 of the [Request](https://fetch.spec.whatwg.org/#dom-request) constructor. 

So it might make sense to set total-bytes as part of [extracting a body](https://fetch.spec.whatwg.org/#concept-bodyinit-extract) in the non-stream case, to ensure the request will have a content-length header. 

At that point I think a request would either:

-  have a 0 content-length header, if the body is null
- have a positive content-length header
- have a chunked content-encoding header(if the body is a stream). 
- have none of the above, if using HTTP/2

And this would seem to be useful information to then decide how to "transmit bytes" as part of https://fetch.spec.whatwg.org/#concept-request-transmit-body. 


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