Add a way to proxy/tunnel ports or view files through code-server

[geiseri]

I am trying to use the docker installed version of the server and can start my application correctly, but I cannot figure out how to connect to it via the browser. On the desktop code I access it on http://localhost:5000. I changed it so that it will listen on all interfaces, but I still cannot contact it from outside the docker. Is there a way to redirect a URL from the exposed site? Or do I need to expose the port in docker and access it that way?

[lucacasonato]

If I understand you correctly you are asking how to expose a port right? You can do this by adding the flag -p 127.0.0.1:5000:5000 to the docker run command.

[geiseri]

This is what I am doing now, but I want to try to do something similar to eclipse che. They allow you to map internal http services to a child mountpoint. That way you only have one port to deal with in a reverse proxy situation.

[infogulch]

This would be really cool to see. Is there a known, fixed list of api routes that codeserver uses? If some routes are guaranteed to be unused, it would allow a proxy to route a subset of http paths on the same domain to different ports in the container.

Say I'm hosting codeserver in a docker container on a server that has a proxy for automatic https, lets say I put it at https://mycodeserver.example.com/. Just by looking at the browser chatter in the network tab of chrome with the app running, I see request paths like /, /webview.html, /ide.0.08cf8d.js, /resource/src/packages/.... I don't see e.g. /api/* anywhere, so for example maybe I can use my proxy to redirect https://mycodeserver.example.com/api/* to a different port on the codeserver container which would then route to my running application I started inside.

But I'm not sure /api/ specifically is safe, codeserver might use it internally and I just haven't seen it yet (same goes for any other path), so I'd really need a list of known used/free http paths before I could do that confidently.

[Egoscio-zz]

@infogulch I like your idea, and I'd like to contribute to brainstorming a way of possibly narrowing down request paths, but I feel like this deviates too much from the OP's original issue. How about a separate issue?

[nhooyr]

Duplicate of #1292