Re: [hybi] Straw poll: Do you miss interjectable WebSocket level control frame? (was: Re: Discontinuation of mux ...)

[Takeshi Yoshino <[e-mail]>]

Hi Arman,

On Tue, Feb 25, 2014 at 9:31 PM, Arman Djusupov <[e-mail]> wrote:

> Takeshi,
>
>
>
> I assume that Tobias means that HTTP/2 should tunnel the WebSocket
> transport “as is” without stripping off the WebSocket headers or
> functionality. If so then I am in agreement with Tobias.
>

I understand this argument. For developers who've built and are already
using RFC 6455 based infrastructure, this approach is very simple and
allows for faster and easier migration.


>
>
> I can’t think of a good reason why can’t we just forward a complete WS
> frame with its full header through the HTTP/2. If I missed an argument
> that was put forward in a previous discussions please do point me to it.
> IMO plain tunneling, just like HTTP is tunneled through TLS, would do
> fine.
>

Please search for Roberto's posts in the HyBi archive [1] and Roberto and
Martin's posts to topics including "WebSocket" in httpbis archive [2].
Basically, for those who haven't deployed RFC 6455 based software but
(planning to) introducing HTTP/2.0, inheriting RFC 6455 architecture
provides no benefit but some design points of RFC 6455 considered to be
harmful rather motivate them to throw away RFC 6455 and redesign messaging
architecture inside HTTP/2.0 that can be applied to the WS API. Another
Roberto's point is that basic messaging units and meta data should be
easily recognized and investigated by load balancers with least knowledge
in addition to HTTP/2.0. Clearly separated thinner layering provides
flexibility but also requires more code and tests.


>
>
> If we strip off almost the entire frame header and we fragment the payload
> so that it is carried by an HTTP/2 frame, we are practically creating a
> new protocol. Such a protocol doesn’t really need to be related to
> WebSocket, however (if we do create this new protocol) it can be transparently
> exposed through the same browser WS API when HTTP/2 is available.
>
>
>

Yes. I just want to deliver some protocol that is scalable under the
browser WS API. Whether it's related to the WebSocket Protocol or not does
not matter so much. Since we don't want to implement two or more protocol
in Chromium to achieve the same goal (multiplexed protocol for WS API), we
need to choose one.

There seems to be disjoint between the two parties. I understand both
argument but need to find some landing point.

[1] http://www.ietf.org/mail-archive/web/hybi/current/maillist.html
[2] http://lists.w3.org/Archives/Public/ietf-http-wg/2014JanMar/