Consider merging WebSocket into HTTP/3

[theoryfate]

Bootstrapping WebSockets with HTTP/2 is specified in RFC8441. The principle is that WebSocket will take up one stream in HTTP/2 and use DATA frame transmission.

The coupling between WebSocket and HTTP/2 is already very high. Why not directly merge into a single protocol? This can be designed to be simpler.

We can design HTTP/3 as a full-featured protocol that supports working in a request/response mode and supports working in instant messaging mode, unifying the application layer transport protocol of the Web.

We can design a special instant communication stream in HTTP/3, through simple handshake, and simple frame encapsulation. In fact, these can directly use the streamlined HTTP/3 header and data format, and the space occupied by compression will be Become smaller, frame encapsulation of WebSocket itself is no longer needed at all

This way we no longer need WebSocket.

[ianswett]

I believe what you're describing is similar to the WebTransport proposal: https://github.com/WICG/web-transport

I also think this issue is likely out of scope for QUIC v1, but I'll let @MikeBishop make the call on that.

[theoryfate]

Yes, my idea is very similar to WebTransport, but it is not exactly the same.

WebTransport defines the ideal target and API, but it doesn't work out how to implement it. My idea is that this goal is implemented inside HTTP/3 instead of defining a new network protocol.

My idea is to add a built-in, reliable, real-time, two-way streaming feature over HTTP/3 that does not require re-authentication when used in an established HTTP/3 connection (it has already been authenticated when establishing an HTTP/3 connection).

Can be initiated by the server, not just the client, initiates or even does not need to handshake, like HTTP/2 directly send a HEADER frame to create a new stream, use a special frame type (such as MESSAGE) to transfer data to create a new stream, reaching 0 -RTT.

Of course, the above transfer function can be disabled using the SETTINGS frame, but it should be turned on by default.

I think the above features can only be done by embedding it in HTTP/3, instead of using the ugly upgrade mechanism like RFC 8441.

Of course, this is a bit radical. After all, the HTTP protocol is a request-response protocol, but now more and more web content needs to be updated in real time, and WebSocket usage will be more and more. Why not integrate directly into HTTP/3 to define more Powerful next-generation HTTP protocol.

Fewer protocols also allow developers to maintain fewer connection state instances, fewer third-party libraries, and fewer server resources.

[DavidSchinazi]

WebTransport also describes how to implement it, one of the ways is over HTTP/3: https://tools.ietf.org/html/draft-vvv-webtransport-http3

It achieves the goal you describe of adding more communication modes without requiring re-authentication.

The current goal of the HTTPBIS and QUIC working groups with regard to HTTP/3 is to ship a minimum viable protocol that suits the needs of the web. What you propose, while a very worthwhile enhancement, is not required for a minimum viable protocol so I don't imagine it landing in QUICv1 or HTTP/3. This can be built as an extension to HTTP/3 or a future version.

[MikeBishop]

This is out-of-scope for HTTP/3. It's not an existing part of HTTP semantics, and the use-case is addressed by extensions and/or protocols on top of HTTP/3.