[Feat]: Allow turning rewrites off or give better rewrites control over asExternalUri

VS Code の mainThreadWindow.ts:65 から開始し、asExternalUri の結果が code-server によってどのように書き換えられるかを、--proxy-domain と CS_DISABLE_PROXY の経路を含めて追跡します。これを Dart Code での openExternal() の使用方法および報告されている localhost 構造と比較します。完了の条件は、workbench 接続を壊すことなく、書き換えを無効化するか origin template を設定するためのサポートされた方法を提供することです。

What is your suggestion?

Allow controlling how asExternalUri() rewrites work beyond current --proxy-domain capabilities or allow turning them off completely.

Why do you want this feature?

Extensions like Dart Code use asExternalUri to open a WebView in the editor with their DevTools. In Dart Code's case, it refuses to function unless it's served off http://localhost:port root, and also requires connection to its WebSocket server on another port.

I use manual SSH port forwarding for these ports and it used to work about a year ago, but now code-server rewrites these URLs with its own port forwarding, which doesn't work with the extension and I found no way to fix it.

Are there any workarounds to get this functionality today?

• I tried configuring <port>.example.com port forwarding, but it doesn't work with the extension
• I can't set --proxy-domain http://localhost:{{port}} because it results in https://httplocalhost%3Aport URLs
• With --proxy-domain localhost:{{port}} VS Code fails to connect to workbench (The workbench failed to connect to the server (Error: Failed to construct 'URL': Invalid URL))
• Setting CS_DISABLE_PROXY=1 && code-server and deleting all the existing port forwards doesn't turn the rewrites off
• Setting remote.forwardOnOpen and remote.autoForwardPorts to false doesn't turn the rewrites off.
• Maybe I'm doing something wrong, but setting VSCODE_PROXY_URI=http://localhost:{{port}} environment variable doesn't produce any result

With CS_DISABLE_PROXY=1 environment variable, remote.forwardOnOpen and remote.autoForwardPorts set to false, when I set a breakpoint on mainThreadWindow.ts:65, I get the following structure:

{
    authority: "example.com",
    fragment: "",
    path: "/proxy/9100/",
    query: "",
    scheme: "https",
}

Some implementation details not very related to the problem, but useful to know: When debugging, I get the aforementioned structure twice, first for the DevTools URL, and the similar one for the debug service URL. While the debug service URL is actually a websocket connection, Dart Code uses http protocol to get the asExternalUri() and then replaces it with ws, since the method doesn't support ws port forwarding.

After the extension receives the mapped url, a webview opens at https://example.com/DEBUGGER_URL, dropping the /proxy/9100 part, which I saw mentioned in the docs, though I don't understand how it works. The webview contains only Not Found error.

When using subdomain port forwarding, devtools just fail to load because of some bug in them.

When I copy the URL to my browser and manually change https://example.com to http://localhost:<port> (in both URI itself and its URI parameter that contains the endpoint for the debug service), the DevTools load and successfully connect to the websocket port I SSH forwarded earlier.

When opening VS Code with port forwarding over http://localhost:8080, I get the following structures from asExternalUri:

{
    "external": "http://127.0.0.1:9100/DEBUGGER_URL",
    "path": "/network",
    "scheme": "http",
    "authority": "127.0.0.1:9100",
}

Which is exactly what I need. But the resulting webview still points to localhost:8080, so the URL gets patched on some stage, but I can't find any lines in Dart Code which would cause that. Unless I'm missing something, my suspicion is that code-server replaces the result somewhere on returning the result to the extension or displaying the webview, but I don't know how to debug the remote side of the extension and need help with that.

The extension also has "Launch DevTools in browser" option, which tries to open https://example.com/proxy/<port>/ when opening VS Code from example.com, and http://localhost:8080/proxy/<port>/ when opened from localhost. If I studied the extension's code correctly, it uses openExternal() method.

Thus my suggested solution is to either allow to specify any sort of origin template in --proxy-domain, like http://localhost:{{port}}, or at least allow rewrites to be turned off so the localhost URIs remain untouched.

Are you interested in submitting a PR for this?

I could try, but I'm not familiar with code-server's code base yet.