Re: 6455 Websockets and the relationship to HTTP

[Amos Jeffries <[e-mail]>]

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.

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.

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

Amos