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

@sleevi To reply to your comments inline...

> I think the complexity of the H/2 path is overstated, and unreasonably
biased towards presumed server-side complexity

There are servers today (such as Icecast) that will probably never support HTTP/2, which work just fine by receiving a stream sent over an HTTP request.  In my opinion, the complexity of going to HTTP/2 is massive for projects like these.  There are 20 years worth of deployments for Icecast alone.

Other servers are often backed by applications that may not work in an HTTP/2 compatible way.  they've been receiving streams of data since their inception.

> while overlooking the client-side complexity (that is, complexity for the JS developer primarily,
although to a much lesser extent the UA developer as well).

It's possible I don't know all of the complexities you're talking about, but it feels trivial to me for the JS developer:

```
fetch('https://example.com/some-stream', {
  method: 'PUT',
  body: someReadableStream
});
```

We can do the equivalent with CLI cURL.  We can integrate this type of thing with most any other HTTP client library in applications.  FFmpeg supports it.  Seemingly the only place we cannot do this is the web.

In other words, streaming a PUT body isn't new... and therefore any intermediate problems you're expecting to hit likely already exist and won't be made worse by simply allowing us JS developers to simplify and bypass a ton of web socket proxy cruft we've had to add, just to make a streaming HTTP request.

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

Received on Friday, 28 February 2020 14:25:43 UTC