Streaming upload

[yutakahirano]

Past discussions: #425, #966, ...

Please also see: other upload-streaming-blocking issues.

Let's discuss whether we want to have the streaming upload feature, i.e., a way to attach a ReadableStream to a Request, on the Web.
Last time we discussed, all the browser vendors agreed that supporting full-duplex (c.f., #1254) would be very difficult, so I'd like to exclude the option from this discussion. Feel free discuss that at #1254 or another issue.

We, Chrome, have a partial implementation, but failed to show its effectiveness thourgh a past experiment.

We have two paths forward:

1. Get more support from other browser vendors and web developers, and ship this feature.
2. Give up this feature and remove the logic from the spec.

Thoughts?

[yutakahirano]

(Feel free to restate your position here even if you've already done that in #425).

[drzraf]

It's a great opportunity to make the web a bit more bidirectional.

ReadableStream means on-the-fly transformation, the first obvious candidate being... encryption.

Use case: I want to submit a form (to an openstack POST-handler) which contains attachments encrypted on-the-fly. In the current situation, client memory is ~ twice the file size what is unsuitable for multi-GB uploads.

The lack of ReadableStream upload incentives the use of chunking as an alternative (which has the additional benefit of being easily resumable).
Since I believe streams find their use for large data (unpredictable size), reliability (resumable/error-handing), if not directly involved, needs to at least be considered by implementations.

[benbucksch]

I'd like to echo #425 (comment) . This feature is desperately needed for streaming media from a client to a server.

The alternatives like WebSockets etc. all need manual, custom code on both the client and server side, which makes interoperability practically impossible. That's more like FTP. The beauty of HTTP is its simplicity.

We can stream from server to client in response bodies, so we should also be able to stream from client to server in request bodies. In the same way that I can stream a video from server to client, I should be able to stream a video or audio from client to server. This avoids having to create custom protocols and servers and clients for streaming media.

[benbucksch]

One important project of mine died exactly at this point, because this wasn't possible.

[ioquatix]

From an implementation point of view, HTTP is pretty elegant, at least, HTTP/1 is. HTTP/2 trades questionable performance gains for elegance, and HTTP/3 goes further in this direction without any real semantic advantages. Honestly, I'm so disappointed that we are reinventing the network protocol at the application layer, but that's probably for another discussion.

Browsers need to implement the full semantics of HTTP. Even since HTTP/1.1 full bi-directional streaming is possible with chunked encoding. Of course you can argue that it's not used in the real world, but it's a true chicken and egg problem, of course if browsers don't support it no one can use it.

From an implementation perspective, I can only imagine that browsers put "full semantics of HTTP" in the too hard basket and instead invent things like WebSockets and WebTransport, WebRTC which are all ridiculously complicated to implement correctly on the client and server, have various compatibility issues and honestly don't solve the problem as well as bi-directional HTTP would.

I respect that I probably don't see the full picture from the perspective of a browser developer, but I have implemented a full HTTP/1 stack in C++ and HTTP/1 + HTTP/2 in Ruby (and hopefully soon 3), both client and server, including on top of that client and server WebSockets, including on top of that, interfaces for web applications to build on. So, I think I do have a pretty good perspective when I say, I wish browsers would just fully commit to bi-directional HTTP vs all these extra layers on top. Not only is it hard for developers, it's hard to communicate the reason why it's built like this, because frankly, the reasons aren't very good.

[yutakahirano]

Thank you for your feedback.

I'm happy to make some more efforts, meaning I'm happy to make another try to spec and implement the minimal viable ship.

• The feature is available only on HTTP/2 or HTTP/3 (Request body streams should use chunked encoding #966).
• Full bidirectional streaming is out of scope (Fetch body streams are not full duplex #1254).

If you are happy with them, I'll fix the spec and implementation, file a TAG review and send an intent to ship to blink-dev. With your support ("developer's opinions"), I may be able to get enough support from API owners.

[ioquatix]

If this is the best middle ground we can find to start with, I support it. However, I'd also say, full-duplex streaming and HTTP/1 streaming are definitely possible in practice, and the only limitation seems to be browser implementors. Because, I've personally implemented all of that already.

It might be useful to allow specs to be full-duplex and to support HTTP/1.1 as optional, e.g. node.js might choose to support this because they don't depend on a browser for the client/server implementation limitations.

[benbucksch]

@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 internal local network, so there's typically no need for 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 using HTTP/1.1, or c) a webpage in a browser on the open web using HTTP/2, or a wild combination of all of those. Custom protocols based on WebSockets, WebRTC or other layers which require complicated server and 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, 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.

[benbucksch]

#425 discussed a number of approaches for HTTP/1.1. A stream could be terminated by dropping the connection, or it could use chunking. My preference would be that both methods work.

[wenbozhu]

I worked with the Chrome team on the experiment mentioned by Yutaka, with Google's user-facing services (gmail etc).

Unfortunately the API designed for the Origin Trial didn't allow us to collect the data needed, i.e. % of broken H1 streams due to chunked TE. The main reason is that HTTPS traffic default to H2+.

To make the experiment work, we need an Origin Trial API that forces HTTP/1.1 over HTTPS.