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

@yutakahirano HTTP/1.1 support is essential for me.

I need this as internal application API between different components of a distributed system. Both end points are usually in the same network, so there's typically no point in SSL encryption, and there will not be valid CA certificates. The clients may be either a) node.js, or b) small devices with an ESP32, or c) a webpage in a browser on the open web, or a wild combination of all of those. Custom protocols based on WebSockets, WebRTC or other layers which require complicated server or client implementations are out of question. The entire point of using HTTP APIs is to create a standard for interoperable devices, with many different implementations, and making it really easy to implement new clients of various kinds, within hours of dev time.

I was really surprised to find out that streaming upload for `fetch()` is not implemented. I took it for granted that if I can download and upload files, and a stream can be returned from server to client, a stream can also be sent from client to server. There are many applications. Essentially all the use cases for server->client streaming, just that the connection is established by the other end.

Such holes in the specs need to be avoided, where it works in some cases but not in others, e.g. file download works, file upload works, stream download works, but stream upload doesn't work. The elegance of HTTP is that there is a simple concept, and you can cover most use cases with this same concept. This is unlike FTP, gopher, and many other more complicated protocols with complex layers and multiple channels that were all superceded by HTTP, due to the power of its simplicity.

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

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