Re: 6455 Websockets and the relationship to HTTP

Sorry to revive an old thread.

On 2016/12/02 12:14, Patrick McManus wrote:
> On Thu, Dec 1, 2016 at 9:33 PM, Andy Green <andy@warmcat.com> wrote:
>
>> The actual game here is "provide a transport for JS WS API on h2".  It
>
>
> indeed - but what I'm trying to get to the root of in this thread is what
> motivates that. If the game is to get it into somebody's charter. that is
> going to need to be crisp. So far I've really only heard 2 strong
> motivators (along with a few complementary smaller ones)
>
> 1] it is inherently a problem that 6455 can only be done on h1 because it
> is left behind the h2 curve. To be honest, this is generally stated as a
> given but it isn't obviously true to me. I haven't heard this fleshed out
> very convincingly - I tried to give some seeds to help build that argument
> in the first message of this thread.. but to my mind there hasn't been a
> convincing case made yet that this is a problem (which isn't to say I think
> the case can't be made).

My understanding is that H1 is, despite keep-alive and pipelining and 
all that, essentially request-response-done, whereas H2 is designed for 
long(er) term relationships. WS also is intended for longer-term 
relationships. So WS and H2 fit together much better than WS and H1. Put 
in a different way, if we had the choice between basing WS on H1 and 
basing it on H2, it would be a slam dunk for H2.


> 2] ws needs mux (and priority and flow control that go with it)  and h2 has
> already solved that thorny problem. I buy this if ws needs mux. I supported
> mux with Roberto in the hybi days and the wg decided against doing it in
> the base version as part of 6455. This seems to be a stronger argument  But
> has the lack of mux been a problem in practice for ws? anecdotes or data to
> support that?

I sure also would like to see some data. But then, has the lack of mux 
in H1 been a problem? If no, why is it in H2? If yes, why is it a 
problem for HTTP, but not for WS?

Regards,   Martin.

Received on Tuesday, 13 December 2016 08:47:56 UTC