Subject: [quicwg/base-drafts] Consider merging WebSocket into HTTP/3 (#2953)

From: theoryfate <[email-masked]>
Date: Sun, 04 Aug 2019 21:22:17 -0700

Bootstrapping WebSockets with HTTP/2 is specified in RFC844. 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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2953

---

From: ianswett <[email-masked]>
Date: Mon, 05 Aug 2019 06:26:27 -0700

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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2953#issuecomment-518233356

---

From: theoryfate <[email-masked]>
Date: Mon, 05 Aug 2019 09:19:51 -0700

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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2953#issuecomment-518301433

---

From: David Schinazi <[email-masked]>
Date: Mon, 05 Aug 2019 09:54:46 -0700

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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2953#issuecomment-518313328

---

From: Mike Bishop <[email-masked]>
Date: Tue, 06 Aug 2019 15:07:46 -0700

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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2953#issuecomment-518862306

---

From: Mike Bishop <[email-masked]>
Date: Tue, 06 Aug 2019 15:07:47 -0700

Closed #2953.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2953#event-2538251769