Skip to content

[Bug]: Slowness when reloading code-server started with --proxy-domain #6088

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
2 of 4 tasks
l0c4t0r opened this issue Mar 17, 2023 · 4 comments
Closed
2 of 4 tasks
Labels
bug Something isn't working triage This issue needs to be triaged by a maintainer

Comments

@l0c4t0r
Copy link

l0c4t0r commented Mar 17, 2023

Is there an existing issue for this?

  • I have searched the existing issues

OS/Web Information

  • Web Browser: Brave
  • Local OS: Windows 11
  • Remote OS: Ubuntu 22.04
  • Remote Architecture: amd64
  • code-server --version: 4.11.0

Steps to Reproduce

  1. run code-server --proxy-domain example.com
  2. run a web service e.g fastapi. on port 8000
  3. reload browser tab for code-server

Expected

Code server in browser should reload quickly
INFO Creating a socket (...) was successful after 250 ms
This step in the browser console completes ~250ms if code server started without proxy domain.

Actual

Blank screen in browser while code server reloads
INFO Creating a socket (...) was successful after 112877 ms
This step takes much longer than usual.
During this time, the web service is running at 8000.example.com and responsive.

Logs

The following error is seen:

[14:49:04] TypeError: res.writeHead is not a function
    at ProxyServer.<anonymous> (/usr/lib/code-server/out/node/proxy.js:11:9)
    at ProxyServer.emit (/usr/lib/code-server/node_modules/eventemitter3/index.js:204:33)
    at ClientRequest.onOutgoingError (/usr/lib/code-server/node_modules/http-proxy/lib/http-proxy/passes/ws-incoming.js:157:16)
    at ClientRequest.emit (node:events:513:28)
    at Socket.socketErrorListener (node:_http_client:494:9)
    at Socket.emit (node:events:513:28)
    at emitErrorNT (node:internal/streams/destroy:157:8)
    at emitErrorCloseNT (node:internal/streams/destroy:122:3)
    at processTicksAndRejections (node:internal/process/task_queues:83:21)

Screenshot/Video

No response

Does this issue happen in VS Code or GitHub Codespaces?

  • I cannot reproduce this in VS Code.
  • I cannot reproduce this in GitHub Codespaces.

Are you accessing code-server over HTTPS?

  • I am using HTTPS.

Notes

No response

@l0c4t0r l0c4t0r added bug Something isn't working triage This issue needs to be triaged by a maintainer labels Mar 17, 2023
@code-asher
Copy link
Member

I briefly attempted to reproduce on 4.11.0 but so far have not seen the slowness with proxy-domain nor have I seen the res.writeHead error.

I used localhost as my proxy domain (so <port>.localhost:8080). For my web service I ran python -m http.server 8000. Might have to try fastapi and a real domain.

@code-asher
Copy link
Member

Code-wise I am not sure how this would happen; the proxy domain flag is checked against the host on each request but crazy for that to take nearly two minutes! Does this reliably reproduce for you when you add/remove the proxy-domain flag?

@l0c4t0r
Copy link
Author

l0c4t0r commented Mar 21, 2023

@code-asher Thanks for looking into it. I tried this again today and was not able to reproduce the slowness. I've been hosting this on a GCP compute engine instance and wonder if there were intermittent issues on that side.
However I am still getting the res.writeHead error in the logs, this only shows up with proxy-domain flag. I am not really familiar with nginx and have just followed guides to get that set up, so I wonder if I have mis-configured something that is triggering this.

This is my nginx file:

server {
    server_name code.example.com *.code.example.com;

    location / {
      proxy_pass http://localhost:8080/;
      proxy_set_header Host $host;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection upgrade;
      proxy_set_header Accept-Encoding gzip;
    }

    listen [::]:443 ssl ipv6only=on; # managed by Certbot
    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/code.example.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/code.example.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot



}
server {
    if ($host = *.code.example.com) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


    if ($host = code.example.com) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


    listen 80;
    listen [::]:80;
    server_name code.example.com *.code.example.com;
    return 404; # managed by Certbot
}

Let me know if there's anything I can do to help test/figure out where the error is coming from.

@code-asher
Copy link
Member

That config looks good to me. The res.writeHead in question runs when the proxy fails to hit the target and I think maybe writeHead is undefined when the request is a web socket.

Aha yup I am able to reproduce with new WebSocket("wss://localhost:8080/proxy/8000") where I have nothing running on 8000.

We will need to handle the code differently, something like this should work.

res.end(`HTTP/1.1 ${statusCode} ${err.message}\r\n\r\n`)

In the meantime, is your app opening web sockets to the right spot?

code-asher added a commit that referenced this issue Mar 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working triage This issue needs to be triaged by a maintainer
Projects
None yet
Development

No branches or pull requests

2 participants