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

Andy Green <> Thu, 27 April 2017 10:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AA5141200DF for <>; Thu, 27 Apr 2017 03:20:26 -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 NQX7jej2OGc8 for <>; Thu, 27 Apr 2017 03:20:25 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 257B81200C1 for <>; Thu, 27 Apr 2017 03:20:24 -0700 (PDT)
To: Greg Wilkins <>,
References: <>
From: Andy Green <>
Message-ID: <>
Date: Thu, 27 Apr 2017 18:19:35 +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: 7bit
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: Thu, 27 Apr 2017 10:20:27 -0000

On 04/27/2017 05:36 PM, Greg Wilkins wrote:
> Takeshi,
> I note that in your drafts introduction you say:
>     when HTTP/1.1 is used as the underlying protocol, full-duplex
>     communication may
>     be broken if the client, server or any proxy chooses to buffer or
>     reject earlier 2xx
>     responses
> Which is a clear and accurate statement of the key problem facing any 
> forever-frame based transport, regardless of what framing protocol is 
> used within those forever-frames.  So while using the standard WS 
> framing is admirable, as is the usage of bidirectional communications, 
> I do not see why this is any more than WiSHful thinking that buffering 
> or simplex proxies will prevent universal coverage of the WS semantic.
> So if I understand your intent correctly, you wish to define WS over 
> HTTP semantics in a way that is transport independent, so it will work 
> for both HTTP/1 and HTTP/2 so that WS can benefit from the single 
> connection muxing available in HTTP/2 when that is available.

IIUI (having eyeballed it now) more precisely it wants to work with 
http/2 and this new fetch / streams on http/1.  It's not needed in 
RFC6455 http/1 which does what it does already.

> The problem with this approach is that the HTTP semantics just does 
> not support full-duplex streaming transport and thus it is bound to 
> fail now and potentially in the future when new proxy standards may be 
> developed.

I don't know enough about this fetch/streams it is trying to work with 
to have an opinion.  However I agree --->

> I think the effort would be better spent working with the HTTPbis 
> working group to get the WS semantic accepted over HTTP/2 framing in a 
> way that distinguishes the content from a normal HTTP message that 
> might be stored and forwarded.

What has happened here is a deliberate failure of the http/2 guys to 
take care of ws in http/2 when they should have during its definition.  
Everything else about http/1 was covered in http/2... it's specifically 
ws that got deliberately ignored even after the lack was pointed out.  I 
dunno what caused that groupthink that ws alone was not worthy of support.

If you accept that is fundamentally what went wrong, you can get to the 
starting point it is enough to fix this to define a way to carry it 
natively in http/2.

How or whether this streams/fetch carries it is less critical because 
RFC6455 already lets stuff work well today in http/1.  So that whole 
thing along with unifying transports is a separate issue I think, at 
least it will be implemented by everyone as a separate project than 
http/2 ws.

http/2 people should go back and properly deal with what they left 
out... which also means the http/2 guys are going in the wrong direction 
trying to outsource this activity to hybi (more accurately, trying to 
squash discussion on HTTPbis about http/2 native ws is part of the same 
"oh the smell from this ws shit on my shoe just won't go away" syndrome 
that led to ws being left out in the first place)... this is their 
problem... first some kind of philosophical problem that ws is beneath 
them, and then a technical one that has already been discussed there.


> regards
> -- 
> Greg Wilkins < <>> CTO 
> _______________________________________________
> hybi mailing list