Skip to content

Incorrect root url detection for WebSocket with any non-root url path #101

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
ICEFIR opened this issue Mar 7, 2019 · 13 comments
Closed
Labels
bug Something isn't working

Comments

@ICEFIR
Copy link

ICEFIR commented Mar 7, 2019

  • code-server version: 1.0.0
  • OS Version: Debian 9, With docker deployment

Steps to Reproduce

  1. Setup Nginx reverse proxy to a different path - i.e. to something.something.com/vscode/
  2. Login works fine, but upon vscode page, it's just a blank page. Client browser console shows its trying to connect to wss://something.somthing.com/, without the correct root-relative path (something.something.com/vscode/), which.... obvious will not work.

Also, I did not find any documentation (or config in general) related to this type of deployment... guess that probably can be improved a bit?

@idoprz
Copy link

idoprz commented Mar 8, 2019

I can also see that getting the webpack_hmr is failing because it looks for it in the host root.

@MrDetonia
Copy link

I'm having the exact same problem. Nginx is set up to run a reverse proxy under a /code/ location, headers set to upgrade the connection for websockets, but I see the page trying to make websocket connections, and GET __webpack_hmr from my root url.

Outside of using e.g. a subdomain and an entirely new Nginx site, I don't see a feasible solution for this; and I imagine having VSCode exist as a sub-directory may be a common setup.

@kylecarbs
Copy link
Member

Ah I know the issue.

Updating https://github.com/codercom/code-server/blob/master/packages/ide/src/fill/client.ts#L95 to contain the browser URL should fix this.

@nhooyr nhooyr added the bug Something isn't working label Mar 8, 2019
@MrDetonia
Copy link

This seems to have been fixed by #149

Have built a fresh image from upstream and tested the same setup that was previously broken - all working.

@si458
Copy link

si458 commented Mar 14, 2019

i have pulled the latest image from https://hub.docker.com/r/codercom/code-server
(March 13, 2019 07:36 PM) and im still getting the 404 error ?

Firefox can't establish a connection to the server at https://192.168.168.77:32770/__webpack_hmr.

sample docker-compose file

version: '2'
services:
  codeserver:
    image: codercom/code-server:latest
    ports:
      - 8443
    volumes:
      - codeserver:/root/project
volumes:
  codeserver:
    driver: local

@betatim
Copy link

betatim commented Mar 14, 2019

Works well with that fix: https://twitter.com/betatim/status/1106195567892402177

@si458
Copy link

si458 commented Mar 15, 2019

i have pulled the latest image again this morning from https://hub.docker.com/r/codercom/code-server (March 15, 2019 05:19 AM) and im still getting the 404 error ?
Firefox can't establish a connection to the server at https://192.168.168.77:32770/__webpack_hmr.

@MrDetonia
Copy link

@si458 Odd, as that fix seems to be included in the latest release:
https://github.com/codercom/code-server/blob/2f27b5df8cc37d047ff93bf842c856c97ad74170/packages/ide/src/fill/client.ts#L96

Are you sure it's the same issue / able to post your nginx config?

@si458
Copy link

si458 commented Mar 15, 2019

@MrDetonia i dont use nginx?
i only use a docker-compose file, nothing special

version: '2'
services:
  codeserver:
    image: codercom/code-server:latest
    ports:
      - 8443
    volumes:
      - codeserver:/root/project
    command: --allow-http --no-auth
volumes:
  codeserver:
    driver: local

@MrDetonia
Copy link

@si458 as I understand it, this issue was specific to using a reverse proxy with nginx (see OP). You may be seeing some other issue that is unrelated.

@si458
Copy link

si458 commented Mar 15, 2019

@MrDetonia your are correct, sorry

ill tag onto the other issue thats been closed but it needs re-opening as its still an issue
#141

@kylecarbs
Copy link
Member

I believe this is fixed. cc: @code-asher

@code-asher
Copy link
Member

Yup, the websocket uses the same URL that serves code-server now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

8 participants