Skip to content
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

[v2] Rewrite code-server to use new web stuff #857

Merged
merged 136 commits into from Sep 12, 2019
Merged

[v2] Rewrite code-server to use new web stuff #857

merged 136 commits into from Sep 12, 2019

Conversation

code-asher
Copy link
Member

@code-asher code-asher commented Jul 17, 2019

This uses the new web and remote functionality VS Code has implemented which has made it possible to shrink the code base by about a factor of ten. It should be much easier to upgrade VS Code versions now and it'll fix a decent number of issues. As the web portion of VS Code matures we'll be able to shrink our patch and maybe even remove it entirely or almost entirely.

There are also some differences in defaults. Mainly things have been made additive instead of subtractive.

  • HTTP instead of HTTPS.
  • No password instead of password. (Have since changed this back.)
  • Default port is now 8080.
  • No longer opens the cwd if no path is given.

Flags have changed:

  • --auth password to enable password authentication. The idea here is to eventually support other authentication methods.
  • HTTPS is enabled automatically if you pass in certificates; no need for a separate flag to toggle it.
  • VS Code options have been inherited so there are some differences there.
  • VS Code does not error on unknown options so code-server no longer does either.

I think v2 is on par feature-wise with v1 except:

  • Can't upload vsix files. (1.37.0 added this)
  • Extension profiling is disabled.
  • Extension tips are disabled.
  • Running tasks doesn't work. (fixed)
  • Can't upload files. (implemented)

Todo:

  • Look into service worker error when using a base path (just need to adjust the scope).
  • Use current page URL for the webview URL instead of trying to figure it out on the server's end.
  • Fix Ctrl + K + O issue.
  • General testing.

The next big thing will be to get language support working which I think should be pretty easy now (that's another big benefit to this rewrite). (Implemented.)

This time around for the patch I opted to keep context because I found that no context made upgrading tricky in the past.

@sabrehagen
Copy link

image

I'm interested in the reasoning on merging with CI failing. What has regressed? Is there a short term goal to get CI passing again? code-server has a big userbase to consider when shipping releases.

@sr229
Copy link
Contributor

sr229 commented Sep 12, 2019

@sabrehagen My CI passes (it provides dailies) so Idk what failed in the CI. I'll investigate later on.

@code-asher
Copy link
Member Author

code-asher commented Sep 12, 2019 via email

@sabrehagen
Copy link

@code-asher sweet, just a technicality 👍

@ddurham2
Copy link

ddurham2 commented Nov 27, 2019

@code-asher, how does this address #241? I'm attempting to run the container in k8s under a path /code-server but cannot get it to work. It gets the GET /code-server/ request, but just returns 404. Is the idea that I have to put an additional nginx reverse proxy after the LB just to make this happen?

Thanks

@code-asher
Copy link
Member Author

@ddurham2 ahh yeah you still need some kind of reverse proxy. code-server needs to see / rather than /code-server.

#241 as I understand it was just about making code-server work behind a reverse proxy. This PR just added a --base-path flag that allowed code-server to properly make redirections.

@sanjayme97
Copy link

--base-path

how to give base path?

@code-asher
Copy link
Member Author

V3 no longer requires a base path so you won't need to pass it in.

If you're still using v2 and you're trying to access code-server at <domain>/my/base/path then you would do:

code-server --base-path /my/base/path

@jrebey
Copy link

jrebey commented Apr 23, 2020

@code-asher I'm running 3.1.1 and while most of VSCode works, there are still things pointing to /static/* which are getting 404 since my code-server instance is being proxied via /vscode. Specifically, the Terminal will not load.

Here's one of the errors:
DevTools failed to load SourceMap: Could not load content for https://mydomain/static/28e91ba70cd70fa9adf3f2e3e3b87631b5667ecf/lib/vscode/out/vs/workbench/services/extensions/worker/extensionHostWorker.nls.js.map: HTTP error: status code 404, net::ERR_HTTP_RESPONSE_CODE_FAILURE

I'm running code-server behind an nginx proxy using the following:

proxy_pass http://code-server:8443/;
# Set WebSocket Proxy
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection upgrade;

This could totally be something I did wrong... any ideas?

@jrebey
Copy link

jrebey commented Apr 23, 2020

Looking at the vscode html returned... I see the following for all "/static/.*" links:

href="./static/28e91ba70cd70fa9adf3f2e3e3b87631b5667ecf/src/browser/media/manifest.json"

Shouldn't this be href="static/..."?

@jrebey
Copy link

jrebey commented Apr 23, 2020

I was able to get this all running with the following changes to the nginx config... this is less than ideal though as it could interfere with locations in my / config...

location /static {
                include /config/nginx/oauth2-proxy.conf;
                proxy_pass http://code-server:8443/static/;
                proxy_set_header Host $host;
                proxy_set_header Accept-Encoding gzip;
                proxy_buffering off;
                proxy_http_version 1.1;
        }

        location /update {
                include /config/nginx/oauth2-proxy.conf;
                proxy_pass http://code-server:8443/update/;
                proxy_set_header Host $host;
                proxy_set_header Accept-Encoding gzip;
                proxy_buffering off;
                proxy_http_version 1.1;
        }

I'm sure I can simplify the config a bit with a location regex... but this was just for a test. I'm down to one remaining error... but that might be a vscode issue:

DevTools failed to load SourceMap: Could not load content for https://mydomain/static/28e91ba70cd70fa9adf3f2e3e3b87631b5667ecf/lib/vscode/node_modules/vscode-textmate/release/main.js.map: HTTP error: status code 404, net::ERR_HTTP_RESPONSE_CODE_FAILURE

@code-asher
Copy link
Member Author

./static/ and static/ are equivalent (both relative to the current URL). Are other static requests working fine? It's just the ones for .map files?

The .map files are only used for debugging code-server so if you don't plan on doing that there's no need to do anything about it.

If you do plan on doing that, it might have something to do with your oauth proxy? Browsers won't send cookies for .map requests unless the cookie's SameSite attribute is set to lax or none, so that could be the source of the issue.

You're right about the 404 error for the vscode-textmate/release/main.js.map file though. It seems to be a bug with vscode-textmate; the module doesn't contain that file when it's downloaded from npm so it looks like it might be incorrectly packaged.

@jrebey
Copy link

jrebey commented Apr 24, 2020

It happens with any request under /static so the UI never loads since all the JavaScript and CSS are located there.

@code-asher
Copy link
Member Author

Bugger, I'm not sure what the issue could be in that case. What are you using to do the oauth? I'll try to run the same and see if I can replicate the issue.

@jrebey
Copy link

jrebey commented Apr 27, 2020

I'm using https://github.com/oauth2-proxy/oauth2-proxy in docker.

I'm using the following containers:

linuxserver/code-server
linuxserver/letsencrypt
quay.io/oauth2-proxy/oauth2-proxy

FWIW, even when I completely disabled the oauth2-proxy on that handler (basically no auth_request directive) I'm still unable to get it working as a subfolder. The oauth stuff was only added once I had a working config by adding the /static and /update locations so I don't want those oauth lines to throw you off.

It didn't work with the following nginx config:

location /code-server {
  proxy_pass http://code-server:8443/;
  # Set WebSocket Proxy
  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection upgrade;
}

When I switched to using a subdomain instead of subfolder, everything works as expected. So I'm not sure why code-server isn't trying to access https://host/code-server/static and instead tries to access http://host/static.

I have all 3 of these containers running within a separate network and the only host exposure is 80/443 in linuxserver/letsencrypt.

Let me know if a docker-compose.yml and some basic config files to replicate the issue in a github repo would help out and I can create that.

@code-asher
Copy link
Member Author

Ahh interesting, I'll try it out today with a subfolder and see what I can turn up.

@code-asher
Copy link
Member Author

code-asher commented Apr 27, 2020

Ohh wait is it the trailing slash? If you browse to: https://host/code-server vs https://host/code-server/? (Might need to add the trailing slash to the location line too.)

With the former, a relative URL will result in https://host/static and with the latter a relative URL will result in https://host/code-server/static.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet