Explorer broken with socket.io polling

[ramymagdy]

Bug Description:

We have to run Theia through a proxy that doesn't support the Connection "Upgrade" for websocket. So instead we need to rely on socket.io long polling.

With the socket.io connection polling the File Explorer act's randomly and no files are opened in the editor ( regardless of the file type ) I have to go randomly clicking through files till I get one of the opening,

Steps to Reproduce:

Apply the following patch

diff --git a/packages/core/src/browser/messaging/ws-connection-source.ts b/packages/core/src/browser/messaging/ws-connection-source.ts
index 24d7d7920..5d4a60a37 100644
--- a/packages/core/src/browser/messaging/ws-connection-source.ts
+++ b/packages/core/src/browser/messaging/ws-connection-source.ts
@@ -202,6 +202,7 @@ export class WebSocketConnectionSource implements ConnectionSource {
     protected createWebSocket(url: string): Socket {
         return io(url, {
             path: this.createSocketIoPath(url),
+           transports: ["polling"],
             reconnection: true,
             reconnectionDelay: 1000,
             reconnectionDelayMax: 10000,
diff --git a/packages/core/src/node/messaging/websocket-endpoint.ts b/packages/core/src/node/messaging/websocket-endpoint.ts
index 187603c77..f98e50ce7 100644
--- a/packages/core/src/node/messaging/websocket-endpoint.ts
+++ b/packages/core/src/node/messaging/websocket-endpoint.ts
@@ -42,6 +42,7 @@ export class WebsocketEndpoint implements BackendApplicationContribution {

     onStart(server: http.Server | https.Server): void {
         const socketServer = new Server(server, {
+           transports: ["polling"],
             pingInterval: this.checkAliveTimeout,
             pingTimeout: this.checkAliveTimeout * 2,
             maxHttpBufferSize: this.maxHttpBufferSize

Or else you may use the following haproxy configurations that will just deny any request with "Upgrade" header.

global
    log /dev/log    local0
    log /dev/log    local1 notice
    chroot /var/lib/haproxy
    stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners
    stats timeout 30s
    user haproxy
    group haproxy
    daemon

    # Default SSL material locations
    ca-base /etc/ssl/certs
    crt-base /etc/ssl/private

    # See: https://ssl-config.mozilla.org/#server=haproxy&server-version=2.0.3&config=intermediate
        ssl-default-bind-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
        ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
        ssl-default-bind-options ssl-min-ver TLSv1.2 no-tls-tickets

defaults
    log global
    mode    http
    option  httplog
    option  dontlognull
        timeout connect 5000
        timeout client  50000
        timeout server  50000
    errorfile 400 /etc/haproxy/errors/400.http
    errorfile 403 /etc/haproxy/errors/403.http
    errorfile 408 /etc/haproxy/errors/408.http
    errorfile 500 /etc/haproxy/errors/500.http
    errorfile 502 /etc/haproxy/errors/502.http
    errorfile 503 /etc/haproxy/errors/503.http
    errorfile 504 /etc/haproxy/errors/504.http

frontend main_test

    bind 0.0.0.0:4000

    # ACL to detect WebSocket connection based on Upgrade header
    acl is_websocket hdr(Upgrade) -i websocket

    # Block WebSocket connections with a 403 Forbidden error
    http-request deny if is_websocket

    default_backend             test

backend test
   balance roundrobin

   server server1 localhost:31852

Additional Information

• Operating System: Linux/Windows
• Theia Version: Git HEAD

[tsmaeder]

@msujew I think you worked on the socket-io infra, right? Any comments off the top of your head?

[msujew]

Sorry for the late response, but I don't have any clue without digging deeper into this: The HTTP fallback should handle the exact same requests/responses as the websocket backend. Unless the connection is literally dropping responses (which it shouldn't, since it's HTTP) I have no idea why this happens.

I'll try to reproduce this once I'm back from vacation.