Re: SETTINGS_ENABLE_CONNECT_PROTOCOL and new protocols

On Wed, Nov 3, 2021, at 01:10, Ben Schwartz wrote:
> In my view, the problem here is WebTransport's use of :protocol.  I 
> think this use is very special and weird:

I started here also.  But MASQUE is similarly weird and it seems like we have more weird cases than simple ones.  Are we making a decision that is right for just one example?

Stefan might have the answer we want.  The generic capability is just the ability to negotiate the use of the bidirectional channel for use by a different protocol.  That might be enough for both websockets and the HTTP/2 mapping of WebTransport.  It's only when we need extra capabilities that we need another negotiation.

What bothers me still is that this is only part of the puzzle.  As Dragana noted, support for a given :protocol at a connection level is not assured.  So while a resource might support the :protocol, they might not support that over the current type of connection.  That means that there are cases where the connection supports the ability to negotiate :protocols in general, the resource supports this specific :protocol, and the combination of the two doesn't.  

For example, my server might support WebTransport, so it declares support for :protocol with SETTINGS_ENABLE_CONNECT_PROTOCOL. However, it doesn't support WebSockets over anything but an upgraded HTTP/1.1 connection.  I don't think that you can just say "well implementing WebSockets for h2 is trivial if you already understand :protocol".  It's not trivial.

This is why I asked the question.  Is a generic negotiation really the best idea here?

Received on Wednesday, 3 November 2021 00:21:00 UTC