Re: [whatwg/fetch] Uploading a Request made from a ReadableStream body (#425)

> @davidfowl reportedly you'll hit middle-ware snags trying to do full-duplex HTTP and therefore still need WebSocket. So as long as that's the case and as long as "Web Transport" isn't really a thing, WebSocket is here to stay.

@annevk Not necessarily, using https limits what middleware can do and things like GRPC already take advantage of HTTP/2 to support streaming. That said, I don't really have an issue with websockets staying, but until the websocket over h2/h3 specs are implemented I'd like to experiment with cheaper ways to do duplex streaming (over HTTP/2, QUIC/HTTP/3 streams instead of a TCP connection). This is a path to doing so. 

> And then while it would indeed be nice to stream request bodies, since you likely have to support resumption of some kind splitting the payload yourself and sending it as a series of requests over H/2 or H/3 might not be that much worse.

The use case I have is for [SignalR](https://docs.microsoft.com/en-us/aspnet/core/tutorials/signalr?view=aspnetcore-2.2&tabs=visual-studio) a real time framework that is transport agnostic (much like socket.io). It already runs over websockets, Server-Sent-Events (EventSource APIs in the browser) and long polling. I'd like to explore an H/2/H/3 bidirectional streaming transport which would pretty much work just like the other transports I've called out but be cheaper in terms of client and server resources. 


-- 
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/pull/425#issuecomment-519274043