Re: [hybi] The future of WebSockets, and the WiSH proposal

Andy Green <> Tue, 25 April 2017 10:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0AA1B12EB86 for <>; Tue, 25 Apr 2017 03:48:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4jlnJ7a1ZLuy for <>; Tue, 25 Apr 2017 03:48:36 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 52858129BA3 for <>; Tue, 25 Apr 2017 03:48:36 -0700 (PDT)
To: =?UTF-8?Q?Lo=c3=afc_Hoguin?= <>, Anne van Kesteren <>
Cc: "" <>
References: <> <> <> <> <> <>
From: Andy Green <>
Message-ID: <>
Date: Tue, 25 Apr 2017 18:47:58 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <>
Subject: Re: [hybi] The future of WebSockets, and the WiSH proposal
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Server-Initiated HTTP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 25 Apr 2017 10:48:39 -0000

On 04/25/2017 05:58 PM, Loïc Hoguin wrote:
> Hello,
> On 04/25/2017 11:10 AM, Anne van Kesteren wrote:
>> On Tue, Apr 25, 2017 at 11:01 AM, Andy Green <> wrote:
>>> Can someone point the rump of hybi-subscribers who have no idea what 
>>> you are
>>> talking about with this "fetch() / Streams" stuff to some definitive
>>> documentation?
>> Apologies, fetch() is basically what replaces XMLHttpRequest and it
>> has slowly evolved to expose streams which in theory allows for
>> full-duplex communication even over H/1:
>> It's still early days implementation-wise though with regards to the
>> streams integration.
> While this looks interesting, it doesn't help any of us with 
> non-browser/non-JS clients, like server-side clients or mobile 
> applications.
> Here are a few things my users would like to be able to do:
> * Make their custom Websocket code work over HTTP/2 or any future 
> protocol (QUIC or other)

Yeah.  I proposed this on the http/2 list before http/2 came out and 
more recently.  It was ignored the first time and the second time, the 
responsible guy was surprised that there was even any non-browser ws 
usage.  So I dunno what planet he's on, but clearly it's not a good 
planet from which to direct the future of ws.

Wow you have a lot of points but I think they are not all generic.

> * Continue using the Websocket sub-protocol feature without having to 
> dedicate an entire connection for it (layering an existing protocol 
> over HTTP has advantages for authentication and routing)

Generally speaking, atm I think by default http/2 looks like the future.

The problem is not that we need to "add mux" to http/1 as Google tried 
and failed to "add mux" to ws, but that the guys defining http/2 
unaccountably dropped the ball when they did not include ws support in 
it already.

> * Have a good media type for the streaming of binary events
> A common pattern my users have when contacting a server is to first 
> request a resource that will stream events, then perform other 
> requests separately.
> Here are the issues commonly encountered right now. I'm assuming here 
> that clients can use HTTP/2:
> * Having to open 2 connections (not the best idea for mobile clients, 
> and uses twice the memory on the server side)

You mean two TCP connections?

Why?  You mean fetching the html that has the scripts and then the 
scripts opening the ws connection?

> * Having to reimplement a custom HTTP/2-like protocol on top of 
> Websocket to avoid having those 2 connections (works, but 
> non-standard, and prone to errors)

Eh... what did you mean then "two connections"?

> * Having to use text/event-stream with base64-encoded binary data 
> (inefficient, especially for larger events)

What's up with ws BINARY?
> * For users who would otherwise be fine with text-based events: having 
> to use text encodings. JSON in particular is very inefficient and puts 
> a heavy strain on the server, switching from JSON to msgpack for 
> example makes my servers load go back to 0 even with tens of thousands 
> of connections. Even if using something other than JSON, there's still 
> the matter of decoding text/event-stream.

... JSON can make a lot of sense when things are less intense. What's up 
with BINARY ws connections though?
> * Having to implement a custom multipart media type for events, for 
> those who go that route. Few do because it's non-standard.

Can you explain what this means?  It sounds kind of specific to whatever 
it is you are doing.

> My users tend to have servers with 10K+ or sometimes 100K+ 
> connections, so we have slightly different needs than most people, but 
> they're still worth considering when defining standards I think.
> On top of that WiSH is easier to integrate on the server because it 
> fits better with the HTTP semantics (using content negotiation, in 
> particular). It would be possible to have common code for 
> text/event-stream and WiSH should one desire to, while Websocket 
> itself makes that less practical.
> I don't really know how the standards process works but I would be 
> really interesting to see WiSH make it in one form or another even if 
> browsers are not willing to implement it, because it would definitely 
> benefit the rest of us.

I did not read the wish stuff yet.  But although http/2 guys are too 
important to deal with ws and pushed it back on hybi to discuss, 
actually decision about the generic scope of wish and integration to 
http/2 is more a decision for http/2 than for ws.  ws is just one 
proposed usecase for it.


> Cheers,