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

From: Greg Wilkins <[email-masked]>
Date: Thu, 27 Apr 2017 11:36:55 +0200

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.

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

regards

-- 
Greg Wilkins <[email-masked]> CTO http://webtide.com

---

From: Andy Green <[email-masked]>
Date: Thu, 27 Apr 2017 18:19:35 +0800

On 04/27/2017 05:36 PM, Greg Wilkins wrote:
>     be broken if the client, server or any proxy chooses to buffer or
>     reject earlier 2xx
>     responses
>
>
> 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.

-Andy

>
> regards
>
>
>
>
>
>
>
>
>
> -- 
> Greg Wilkins <[email-masked] <mailto:[email-masked]>> CTO 
> http://webtide.com
>
>
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi