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

Loïc Hoguin <> Tue, 25 April 2017 09:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 734DD129BF3 for <>; Tue, 25 Apr 2017 02:58:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.699
X-Spam-Status: No, score=-4.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vfiPNQltSW2V for <>; Tue, 25 Apr 2017 02:58:50 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 171F4129C5E for <>; Tue, 25 Apr 2017 02:58:49 -0700 (PDT)
Received: from [] ([]) by (mreue103 []) with ESMTPSA (Nemesis) id 0MNvNj-1cvVOB1dhT-007UxU; Tue, 25 Apr 2017 11:58:44 +0200
To: Anne van Kesteren <>
References: <> <> <> <> <>
Cc: "" <>
From: =?UTF-8?Q?Lo=c3=afc_Hoguin?= <>
Organization: Nine Nines
Message-ID: <>
Date: Tue, 25 Apr 2017 11:58:42 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:F3vjtBoHPurJ14btFwKrQ7t5rWpC/Aak8+8mxCn5P57Nb0wCTay qGHsIlmujF4c4jNQjWwZ7TWkf3lHwo7/B1g00XaksAbyPCTCKouT08r4Us7e9rQRViBnM3P U22eyfMjDhyARmyk4njtQnUk935fs33+iUMHAgbgcKxmtTnQnl1JgM8cU623+jUvMTi0Y/j iUUY+pO1BL1/ZJMoL81Lw==
X-UI-Out-Filterresults: notjunk:1;V01:K0:5iVJaGC/zIA=:kPURWLWJ5Po+t60NWqQKPS 9svAR90FIk1UJ3S27hM9eP4SI3ZEVBlptUacEBJKrSryfDXN6CFlqvag4hy1g24u8S8lecCq5 VIFXC18pLcAcjUpQEIQXm+CNHckcM/1gq94CPl6iXgxguqrWLX14a6FQksK4G8vZ1pymMO1oJ 78EKeOoInWRpOY/V2r95bQJBL0WJAY+Bw+2eJ3Tw9uDGijKGw9vpxak87gT5GuQjS5krnszPy o6J+5y1pnzUweD4tPTqBtxh8umGKGxqCaT9WS729gdIJTmCRV0Gg5HDmzrt7V0+KPNgwJj8gy 4hhApz5aLX/ctHoaj2yf9ykjL31LGQR6HO3gNCfyRpzVKZqRiZ2VctFTRMrOrd7oypxYmQkb7 fYDs/0UJPQR5/hvnK1bOCdgBqyWYWXSseAspIWBvyxfgl/c0LD2/F0XDdWCLAD7oe8TbPeymO lY8GazlrLvjLDw8zqA6KzRWFOOTwe4mk5tO6yiISYEikBhbU+fPr6IKZKEpgvHRaAJT1E/bAJ OM2kiDsDplHScixzChiB6xMOCqVXM2WCReSDepE0t1/lOrYVVw5ErKTzhXjw4bEQIk5y1Kqs7 pkCm2vGggmGkIO+RH93yETX9fosHCsCKvHhC226gx9vzRYNbPwoaTfyojqIrkuHqzLf3hac/o 3203UTwTqHNcxfOzSUHJxQnpJUWwxlRQPtUkuKImTO4OrI/7FAJMxCBfrBYpS5xitn/fQJGn5 mwQ93tz8mnuAUzqw
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 09:58:52 -0000


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)

* 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)

* 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 

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)

* 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)

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

* 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.

* Having to implement a custom multipart media type for events, for 
those who go that route. Few do because it's non-standard.

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.


Loïc Hoguin