The base path actually doesn't have anything to do routing incoming requests. That's the job of a reverse proxy. We use the base path to redirect from the login page and to set some headers to the root path. If we made this change then this could break reverse proxies that are properly configured. For example if someone configured their path to be `/vs` then all of our `/vs` paths will stop working because the `vs` gets stripped out. When receiving a request to `/code/some/path` the reverse proxy should route that and code-server should receive it as `/some/path`, meaning the base path is already stripped. So the linked issue most likely has to do with a misconfigured reverse proxy (or isn't using one at all, in which case there is no need for the base path in the first place). Hopefully that makes sense. Maybe we should write a message to stdout when the `base-path` flag is in use explaining some of this?

I think all of those applications provide a base path exactly for the purpose of putting them behind a reverse proxy. Is that not the case? I'm not clear on what the benefit would be of using a base path without a reverse proxy. Suppose you host code-server at example.com and then provide a base path of /vs so it's accessible at example.com/vs. Why not let it be accessed at example.com and skip the base path entirely? Nothing can be hosted there anyway since code-server is already there. Also after this change a reverse proxy working today at example.com/code would require you to access code-server at example.com/code/code. I can't think of any implementation that wouldn't have this problem. Let me know if I'm missing something!

Ahhh, so this is for proxies that cannot rewrite the URL before passing it along to code-server. That makes sense. I'm still not sure how best we can support this scenario without breaking it for proxies that do support that like I previously mentioned. We would need to know beforehand whether the proxy was rewriting the URL or not so we can act appropriately. I'm open to ideas on this. Maybe a new flag like `--proxy-path`?

Or maybe `--rewrite-url`.

If the base path just so happens not to be any path that code-server itself used then everything would be fine. That does seem likely, but it's not something I'd feel comfortable relying on. For example suppose you hosted code-server at `example.com/vs` with `--base-path=/vs`. Then suppose code-server itself has an endpoint at `/vs` and a request is made to example.com/vs/vs. Without a rewriting proxy the result is /vs. All is well and the /vs endpoint is served. With rewriting the result is / and the homepage is served instead. This could be solved by not passing the base path if you're using a rewriting proxy, but unfortunately the base path would still be necessary for redirections and for setting certain headers (like the base path for service workers). I'm not sure we'll be able to have consistent rewriting behavior without first knowing whether the URL has already been rewritten, and the only way to know that is to be told by the user. Maybe we could add a boolean flag `--rewrite` which turns on URL rewriting? When `--base-path` is set we could also output some text about `--rewrite` to raise awareness. I'm definitely open to other solutions if there are any.