As a part of Bug 1772213, we discovered we needed a server for testing with the following behaviour: Http2 Server without h2 websocket support, but has h1.1 websocket support. So when we try to connect to it it is capable of falling back to h1.1 for the websocket connection.

We briefly considered creating a new server similar to the existing NodeWebSocketHttpServer and while the solution for our purposes will likely be similar it was considered out of scope of Bug 1772213.

In summary the essence of this task are:

1. Build the server capable of doing this.
2. Add a test to our websocket xpcshell-test suite that exercises the desired behavior.

So, createSecureServer has an allowHTTP1 option.
Presumably, what we need to do is to (conditionally) add it to the options dict. Then, in the CONNECT handler, we can check if the request is using http2 and if so close the stream with http2.constants.NGHTTP2_HTTP_1_1_REQUIRED

Given the discussion around Bug 1815545, I'm thinking we need at least these two tests:

• h1.1 ws fallback when no existing h2 conn (h2 and h2-ws server support shouldn't matter)
• h1.1 ws fallback when existing h2 conn with h2 support, but no h2-ws support

Valentin, can you:

1. Confirm these make sense
2. Note additional tests we may need

(In reply to Ed Guloien [:edgul] from comment #2)

Given the discussion around Bug 1815545, I'm thinking we need at least these two tests:

• h1.1 ws fallback when no existing h2 conn (h2 and h2-ws server support shouldn't matter)

Right, if we have no H2 connection to the server open, we should use H1 from the start.
According to Chrome's behaviour and RFC 8441 we should also use H1 if the existing H2 connection didn't receive a SETTINGS_ENABLE_CONNECT_PROTOCOL settings parameter - ie GetWebsocketSupport() != WebSocketSupport::SUPPORTED - we should also have a test for this.

• h1.1 ws fallback when existing h2 conn with h2 support, but no h2-ws support

Valentin, can you:

1. Confirm these make sense
2. Note additional tests we may need

The server could signal that it doesn't support WS over H2 in several ways:
Close the stream with http2.constants.NGHTTP2_HTTP_1_1_REQUIRED
Return 421 https://httpwg.org/specs/rfc9110.html#status.421
Return 505 https://httpwg.org/specs/rfc9110.html#status.505

We should make sure we have a test for each of them.

Ok, to summarize then this is the list of tests we need:

0. h2 ws connection when there is pre-existing h2 conn with h2-ws support
1. h1.1 ws fallback when no existing h2 conn (h2 and h2-ws server support shouldn't matter)
   2. h1.1 ws fallback when existing h2 conn with h2 support, but we don't yet know yet about h2-ws server support
2. h1.1 ws fallback when existing h2 conn with h2 support, but no h2-ws support (via http2.constants.NGHTTP2_HTTP_1_1_REQUIRED)
3. h1.1 ws fallback when existing h2 conn with h2 support, but no h2-ws support (via 421)
4. h1.1 ws fallback when existing h2 conn with h2 support, but no h2-ws support (via 505)

Looks good.

(In reply to Ed Guloien [:edgul] from comment #4)
h2 conn with h2 support - I think you mean h2 conn with h2-ws support, right?

2. h1.1 ws fallback when existing h2 conn but we don't yet know yet about h2-ws server support

I think that might be difficult to test. If we have an existing h2 conn, presumably it should have already received a settings frame?

(In reply to Valentin Gosu [:valentin] (he/him) from comment #5)

Looks good.

(In reply to Ed Guloien [:edgul] from comment #4)
h2 conn with h2 support - I think you mean h2 conn with h2-ws support, right?

2. h1.1 ws fallback when existing h2 conn but we don't yet know yet about h2-ws server support

I think that might be difficult to test. If we have an existing h2 conn, presumably it should have already received a settings frame?

Agree. This is racy and not easy to test.

Thanks, I've modified the above, but for my understanding its possible (but unusual) to have an h2 connection with a late SETTINGS frame, right?

It is possible, yes, but we should probably treat it as not-supported, just in case. If you manage to make the server do that, go for it.