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

theoryfate <> Mon, 05 August 2019 16:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 696C91202C2 for <>; Mon, 5 Aug 2019 09:19:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qZKJy5uuV1TE for <>; Mon, 5 Aug 2019 09:19:52 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 355E41202A4 for <>; Mon, 5 Aug 2019 09:19:52 -0700 (PDT)
Date: Mon, 05 Aug 2019 09:19:51 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1565021991; bh=HsODlM/BmJgL5YRKBq/vE6lzYWkCY6jwJ5ugYA7MFvs=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=iZLmcnyazpFUX6qHjce83duQgH+UiZUp2sH027r//Nj65tBOPqFsaPn6AUCfWnoal 9veumHmQNqW2ydYV9HxmKt1U0NWPwdtuTLa8PnbVp5eMhUJQSn5bmxTtElfjA5spMA YBrblSnWLl9Ah8NMwy5rN8IGEyi2u/sNkHb06nPA=
From: theoryfate <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/2953/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Consider merging WebSocket into HTTP/3 (#2953)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d48572753a43_331e3fe91d6cd96421024e"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: theoryfate
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 05 Aug 2019 16:20:06 -0000

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: