Schema-less HTTP_PROXY and HTTPS_PROXY env vars should maybe assume `http`

[williammartin]

This would solve...

Currently, I'm working on gh and copilot CLIs, and we use undici in the latter. We had a report that gh supported schema-less HTTP_PROXY (e.g. HTTP_PROXY=localhost:9000 gh ...) but copilot did not.

When I looked into this, I saw that the EnvHttpProxyAgent passes the env vars verbatim to the underlying client. However, in Go, which gh is written in the proxy env var behaviour is as follows:

The environment values may be either a complete URL or a "host[:port]", in which case the "http" scheme is assumed. An error is returned if the value is a different form.

I'm not sure whether this is behavior you really want, since it may be surprising, but I thought I'd bring it to your attention with a point of comparison for your consideration. Cheers.

[metcoder95]

I believe we need to align to that behavior, as also curl follows a similar approach

[williammartin]

I will buy you 1 stroopwafel from Albert Cuyp Market if I can remove the code I put into copilot to do this.

[metcoder95]

Now we are talking. Add poffertjes and this is done by Tomorrow

[mcollina]

cc @joyeecheung

[Coderxrohan]

Hi @mcollina & @metcoder95
This makes sense to me, and I agree aligning with Go and curl’s behavior is the right move here.
I can take this and open a PR to normalize schema-less HTTP_PROXY / HTTPS_PROXY values (assuming http://) with appropriate tests, if that works for everyone.
Happy to get started — please let me know.

[mcollina]

You'd need a matching PR to Node.js as well for the hold http.request