Re: 6455 Websockets and the relationship to HTTP

On Fri, 2016-12-02 at 14:53 +1300, Amos Jeffries wrote:
> On 2/12/2016 2:13 p.m., Kazuho Oku wrote:
> > 2016-12-02 10:00 GMT+09:00 Mark Nottingham:
> > 
> > > 
> > > > On 2 Dec. 2016, at 11:56 am, Kazuho Oku wrote:
> > > > 
> > > > 
> > > > 
> > > > 2016-12-02 9:19 GMT+09:00 Martin Thomson:
> > > > On 2 December 2016 at 11:09, Mark Nottingham wrote:
> > > > > In particular, my recollection of the outcome of the
> > > > > discussion of WS
> > > 
> > > in H2 was that a new SETTING or a new ALPN token could be used to
> > > indicate
> > > that a connection supports both H2 and WS. If there's a problem
> > > with doing
> > > so, that would be good to talk about as well. Especially
> > > considering QUIC.
> > > > 
> > > > There seems to be some reluctance to exercise that option.  I
> > > > don't
> > > > understand why; I've a bunch of candidate theories, but none of
> > > > them
> > > > make a lot of sense.
> > > > 
> > > > 
> > > > My understanding is that the cons of using SETTINGS only is
> > > > that it
> > > 
> > > requires an additional roundtrip on connection establishment.
> > > I've heard
> > > people oppose to the use of ALPN since they want to use both H2
> > > and WS (and
> > > possibly DNS?) on the same connection.
> > > 
> > > The semantics of the ALPN token can be "this connection supports
> > > H2 *and*
> > > WS."
> > > 
> > > It's true that taken to an extreme, this could lead to a
> > > combinatorial
> > > explosion.
> > 
> > 
> > Agreed. While I believe it would be a good idea to have some kind
> > of
> > mechanism to restrict the use of an H2 connection, a client need to
> > be
> > forbidden for making an anticipation that the connection can also
> > handle
> > HTTP requests.
> 
> Please don't go there. The 'h' in h2 means HTTP by definition.
> 
> WS/1 has its own TCP based sockets etc for use by connections without
> HTTP.

ws does not exist standalone without http first, since the ws protocol
is negotiated in http before the upgrade and there's no way to do it
after the upgrade.

The actual game here is "provide a transport for JS WS API on h2".  It
does not need to retain any relationship at all to "WS/1" transport
implementation.  Eg as was discussed here a long time ago there may be
a way for the whole overkill 64-bit ws fragment size business to go and
just use h2 framing.

> An ALPN for that or for a separate WS/2 protocol spec that references
> HTTP/2 mechanisms and framing as a re-use (like ICAP with HTTP/1)
> should
> be sufficient.

Since there will be servers that support ws/2 and those that don't,
something is needed.  Whatever it is preferably shouldn't force new tcp
connections or roundtrips on ws/2 needlessly.

> But not re-defining h2 to mean non-HTTP-only traffic.

-Andy

> Amos
> 
>

Received on Friday, 2 December 2016 02:34:13 UTC