On Tue, Nov 02, 2021 at 01:56:17PM +0100, Stefan Eissing wrote:
> I think it's beneficial to differentiate between a HTTP capability, like
> Extended CONNECT, and something like "supported protocols". Because if
> a specific protocol is supported or not depends on where the CONNECT
> is really going to. E.g. one has to do it in order to learn if a 
> protocol is supported or not.
> SETTINGS_ENABLE_CONNECT_PROTOCOL says: "I, the server know about
> H2 CONNECT and :protocol and my responses will be in accordance to
> its definition." It does NOT say: "I support websockets".
> hop-by-hop vs. end-to-end.
> As Willy noted about HAProxy, some backend connections will support
> it, some won't. The client needs to really say where it wants to go,
> e.g. open the stream to find out. But without the CONNECT capability,
> there is no use in trying.

Or worse yet, there might be chained reverse proxy, and as result some
resources support it, and some do not... On the same backend from the
reverse proxy perspective.

> Now, if WebTransport requires some additional capabilities, *on
> the server it talks to* those seem to be what SETTINGS are for.
> On scanning <>
> I was so far not able to detect those. All WT_ frames seems to happen
> inside the H2 STREAM's DATA, but maybe I got that wrong.

It is not just question if WebTransport is special (apparently no), but
Websockets is special, due to extended negotiation (to ensure server
actually supports it) it does. Specifically, if translating Websockets
from HTTP/2 to HTTP/1.1 backend, the reverse proxy must synthethize a
fake key (even if just always fixed one).


Received on Wednesday, 3 November 2021 18:23:42 UTC