Disable http fallback after successful websocket connection

[msujew]

What it does

Closes #10261

Simply disables the fallback by setting the allowed property on the fallback options to false once a websocket connection has been established.

How to test

1. Start Theia (Browser) on a remote server
2. Open the Theia window in your browser
3. Disconnect from the remote server (unplug your ethernet)
4. The http fallback should not activate
5. After re-establishing network connection, Theia should re-establish its connection as well.

Review checklist

• As an author, I have thoroughly tested my changes and carefully followed the review guidelines

Reminder for reviewers

• As a reviewer, I agree to behave in accordance with the review guidelines

[paul-marechal]

I feel like this HTTP fallback depends on where/how a Theia instance is deployed, and as such I'm wondering if it's a good idea to always fallback to it? Assuming a WebSocket connection is supposed to work, is it a good idea to try to use HTTP if that fails?

I'm thinking that we could have an option like connectionType: 'single-websocket' | 'http-long-polling' to have Theia explicitly operate in one mode or the other?

[msujew]

I feel like this HTTP fallback depends on where/how a Theia instance is deployed

@paul-marechal Well yes, but also no. It depends more on the network configuration of the user. The main use case for the http fallback is for users in heavily firewalled corporate environments where websockets are blocked. The ones responsible for the deployment don't really know, whether their users will be restricted to http only.

I'm thinking that we could have an option like connectionType: 'single-websocket' | 'http-long-polling' to have Theia explicitly operate in one mode or the other?

I'm not really in favor of that, since the long polling option is considerably slower in a lot of cases, where a lot of data is send between the clients.

Instead, I would change the default implementation to prevent using the http fallback solution. Downstream users would have to explicitly enable the option. WDYT?

[paul-marechal]

I understand now, you are right. We can keep the HTTP fallback and forget about making it configurable.

[paul-marechal]

Code LGTM

[paul-marechal]

But this got me thinking about what we do with this WebSocket multiplexing and HTTP fallback, is there any advantage to doing it ourselves over using https://socket.io/ ?

socket.io supports multiplexing, reconnection, and HTTP fallback.

[msujew]

is there any advantage to doing it ourselves over using https://socket.io/ ?

There isn't, I just didn't know about socket.io so far. I will create an issue for that and try integrating it into Theia when I have some time for that.