Fetch: Request's total bytes isn't set

[jakearchibald]

https://fetch.spec.whatwg.org/#concept-body-total-bytes isn't set for requests, unless the input is a Request object.

Feels like it should be set in https://fetch.spec.whatwg.org/#concept-bodyinit-extract for non-stream sources.

[annevk]

cc @yutakahirano

[wanderview]

It would be nice, though, to acknowledge the size can be unknown. Zero really isn't a good representation of this.

[annevk]

I really want to remove this field and for responses we can look at the Content-Length header (at least for HTTP/1, guess we might have to write/look at some XMLHttpRequest tests to see how the progress events behave).

For non-stream requests the main difficulty will be getting a length out of https://fetch.spec.whatwg.org/#concept-bodyinit-extract when _object_ isn't a stream. That might also involve acknowledging that some serialization happens on the main thread. FormData is the trickiest as it can hold blobs so you would partially serialize it and then use the size of the blobs to calculate the remaining space that is required. Perhaps this can be implementation-defined until we have FormData serialization itself defined?

[annevk]

Here's my plan:

• Define convert BodyInit object to bytes routine that returns a tuple of a byte sequence and null or a multipart/form-data boundary. This will synchronous but implementations can optimize.
• Define a size of BodyInit object routine that invokes convert and returns the length. We'll use this to set the Content-Type header in requests. (I kinda wanna use <a for="BodyInit,byte sequence">length</a> there, but if that's not a thing we'll just branch.)
• Make extract use convert as well instead of all the "actions".

Add a bunch of notes that encourage implementations to optimize this. All ears to better ideas though.

[annevk]

My plan does not work for Blob and FormData: https://github.com/whatwg/html/issues/6424. The other types should probably still be eagerly converted to a byte sequence...

So maybe we should have convert and that returns a tuple of

• a byte sequence or a read operation of sorts
• a length

but it's still rather inelegant to do extract and length (which would both use convert) determination separately. So maybe body should store a length after all. (Though we should also be clear that it's different between requests and responses as for responses it can lie, especially with service workers and maybe also with H/2 and H3/, which don't really have that concept although if you specify Content-Length maybe it's still required to match?)