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

From: Wenbo Zhu <[email-masked]>
Date: Fri, 9 Jun 2017 18:55:53 -0700

Hi Greg,

On Thu, Apr 27, 2017 at 2:36 AM, Greg Wilkins <[email-masked]> 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.
>
WiSH as a framing format (MIME type) doesn't assume any specific L7
protocol. The above text is a warning against deploying long-lived & duplex
bidi over HTTP/1.1, but short or simplex HTTP/1.1 transactions can
certainly use WS framing v.s. SSE or application defined framing.

>
> 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.
>
This is not true. The HTTP/2 spec explicitly require proxies to allow early
2xx responses. There are also environments where proxies are controlled by
services (inc. no proxy).

>
> 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.
>
For e2e encrypted traffic, proxies really shouldn't buffer anything, or WS
will have the same issue. Otherwise, the C-T alone could serve as the
signal.

Maybe it's time to update https://tools.ietf.org/html/rfc6202. A lot of its
content seems out of date, or incorrect, or applicable to WS too (or any
TCP based protocol). We now also have data that shows how often WS
connections are broken in the wild.

- Wenbo

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

---

From: Tobias Oberstein <[email-masked]>
Date: Sat, 10 Jun 2017 15:18:22 +0200

>> The bottom of the background section of the I-D
>> (https://tools.ietf.org/html/draft-yoshino-wish-02#section-2) is
>> unintentionally (I forgot to update it) left to be talking about using
>> WiSH framing over fetch()/Streams to improve the WebSocket ecosystem
>> without introducing any dedicated browser code. This is also a
>> possible option though it requires developers to include Polyfill in
>> their code.
> 
> The basic problem underneath all this is the guys who defined http/2
> considered ws so declasse

This was also my impression, Google powerplay (in this case), trying to 
shove sth down everyones throat, mostly skewed towards their very 
specific interests.

HTTP/1.1 + caching + WebSocket is a complete solution that works for me, 
I just don't need HTTP/2 nor WebSocket over HTTP/2.

 From my point of view, the "future of WebSocket" is bright as the 
technology stands.

I'd rather take up another initiative at WebSocket multiplexing and/or 
message priorization extensions.

/Tobias