Re: [whatwg/fetch] Streaming upload (Issue #1438)

@lucacasonato wrote:
> browsers are unable to handle [it] at this time

Of course, otherwise we wouldn't be here talking about it. As a Firefox developer, and having worked on the Firefox network library in the past (but not currently), I don't see a reason why it can't be done.

> I have no idea what happens if the request body stream is endless

That would be an important case to spec properly, because live streaming is the whole point of why I need streaming uploads.

Other cases can be worked around with `Buffer`s. Live streaming cannot, because not even the size of the upload body is known. We can already send large bodies (with workarounds like `Buffer` and `File`, which can do random-access of files, even on slow file servers, even without buffering before starting the upload), and we can do live streaming downstream from server to client, but there's currently no way to do upstream live streaming from client to server. If you spec it as [you proposed](https://github.com/whatwg/fetch/issues/1438#issuecomment-1158981343), it would be unusable for exactly that one case which absolutely needs streaming uploads and which cannot be done at all currently.

[yutakahirano](https://github.com/yutakahirano) wrote:
> assume the full-duplex mode is specified

Thanks for the suggestion, but you specifically excluded full-duplex from the spec for the time being, so it would remain impossible.

"Full duplex" would be like a phone call, whereas I'm talking about "podcast" or "security camera" mode, where only one side sends. At no point are both sides sending at the same time. There's only an upload, and [the steps could be strictly sequential](https://github.com/whatwg/fetch/issues/1438#issuecomment-1160612085), including the headers.

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

Message ID: <whatwg/fetch/issues/1438/1161580974@github.com>

Received on Tuesday, 21 June 2022 10:49:35 UTC