Internal proxy server doesn't work if http proxy is set

[mfukala]

Internal code-server's proxy for accessing services doesn't work if http proxy is configured.

Test case:

1. create vscode extension that runs http server that returns "ok" on /status route, bind the server to port 3000
2. install the extension into code-server
3. run code-server --auth=none -vvv (so curl examples below work w/ auth) from an environment where http_proxy, https_proxy and no_proxy is set (ensure address 0.0.0.0 is in no_proxy)
4. curl http://localhost:3000/status
5. => you get OK response
6. now (assuming code-server runs on port 7777) via proxy: curl http://localhost:7777/proxy/3000/status
7. => you get 500 response with message "Maximum callstack exceeded"

Following code calls itself in an endless loop:

    at ProxyAgent.callback (/usr/local/Cellar/code-server/3.10.2/libexec/node_modules/proxy-agent/index.js:215:11)
    at /usr/local/Cellar/code-server/3.10.2/libexec/node_modules/agent-base/dist/src/promisify.js:6:16
    at new Promise (<anonymous>)
    at ProxyAgent.promisifiedCallback (/usr/local/Cellar/code-server/3.10.2/libexec/node_modules/agent-base/dist/src/promisify.js:5:16)
    at ProxyAgent.addRequest (/usr/local/Cellar/code-server/3.10.2/libexec/node_modules/agent-base/dist/src/index.js:187:38)
    at ProxyAgent.callback (/usr/local/Cellar/code-server/3.10.2/libexec/node_modules/proxy-agent/index.js:215:11)
    at /usr/local/Cellar/code-server/3.10.2/libexec/node_modules/agent-base/dist/src/promisify.js:6:16
    at new Promise (<anonymous>)
    at ProxyAgent.promisifiedCallback (/usr/local/Cellar/code-server/3.10.2/libexec/node_modules/agent-base/dist/src/promisify.js:5:16)

The reason is monkey patching of http(s).globalAgent done in proxy_agent.js.
The code in node_modules/proxy-agent/index.js (#httpOrHttps) is supposed to return bare http(s).globalAgent in case the processed http request is not supposed to be proxied but it returns the monkey patched instance which is the initiator of the call.

A very ugly workaround is to ensure proxy_agent#shouldEnableProxy returns false by adding "example.com" to no_proxy as the code comment suggests :-)

// But that's drastically unlikely.
function shouldEnableProxy() {
...```

[Chilipp]

hey! thanks a lot @mfukala for this workaround! it would have taken me hours to come up with such a solution. I can confirm that setting an environment variable like NO_PROXY=example.com, <some-other-domains> works well!

Are there any ideas how to solve this? Or is this part of the investigation in #3841?

[jsjoeio]

Thank you for the detailed notes, explanation of how to test and solution for fixing ♥️

Or is this part of the investigation in #3841?

I guess it is part of that investigation now! The plan is to add more tests for that part of the codebase. So now, we can fix that issue and add a test thanks to @mfukala's work!

[jsjoeio]

I can't promise when we will get to this, but I'll move it to "On Deck" meaning it's ready to be placed in an upcoming version milestone.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no activity occurs in the next 5 days.

[Chilipp]

@jsjoeio do you know if this has been solved? I must admit that I did but test it within the past couple of months

[jsjoeio]

@Chilipp I haven't tested it recently (or implemented a fix specifically). So you're saying you did test it and it's fixed?

Otherwise, I wonder if you can simplify the repro steps and I can test

[code-asher]

Closing for inactivity. But also this might be OK now? I think we only monkey patch in the code-server process, not in the extension host.