1.45.3 breaks proxy env variables impact on deno upgrade

[oscar6echo]

How to replicate (Linux):

From version 1.45.2 in corp env with env variables HTTP(S)_PROXY set do deno upgrade.
It works and deno --version shows new version 1.45.3.
Do deno upgrade again and the external host is unreachable.
I infer that proxy env variables are no longer taken into account (?).

NOTE for other users:
To downgrade to 1.45.2, do curl -fsSL https://deno.land/install.sh | sh -s v1.0.0 with curl proxy env variables http(s)_proxy set.

[bartlomieju]

Most likely related to #24632

[oscar6echo]

Fast ! 🚀
Thx

[oscar6echo]

Actually the problem is still there in 1.46.0: Pls reopen the issue.
Behind a corp proxy, I cannot deno upgrade after 1.45.2 but it does work for this version.
Was the fix mentioned above merged ? released ? tested behind a proxy (maybe not that easy) ?

See below the error I have:

• OS: RHEL8
• config:

# deno
BUCKET_ID=$(ls /DATA)
export DENO_INSTALL="/DATA/$BUCKET_ID/.deno"
export DENO_INSTALL_ROOT=$DENO_INSTALL/bin
export DENO_DIR=$DENO_INSTALL/.cache
export DENO_CERT=/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
export DENO_TLS_CA_STORE=system
export PATH="$DENO_INSTALL_ROOT:$PATH"

# proxy
export HTTP_PROXY=xxx
export HTTPS_PROXY=xxx

• screenshot

So for a corp user at the moment the only way to manage upgrades is:

• check out release page
• manual reinstall curl -fsSL https://deno.land/install.sh | sh -s v1.46.0

[seanmonstar]

I see the error message mentions proxy authentication required. Perhaps there was a change in exactly how the credentials for a proxy are parsed/detected. Would you mind sharing what protocol and format your proxy URL is? I don't need the values, just the format.

For example, HTTPS_PROXY=http://user:pass@host?

[oscar6echo]

The format I use is HTTPS_PROXY=http://username:url_encoded_password@hostname:port

For the avoidance of doubt, by url encoded I mean as described here.
Example: url-encode(toto&#*) = toto%26%23%2A

[bartlomieju]

@seanmonstar I guess it might be the same problem as #24705 - I probably missed handling that scenario for deno upgrade and FileFetcher.

[oscar6echo]

Probably related ?
I have noticed that other CLI subcommands also fail with proxy auth.

Same settings as comment above except latest version.

[bartlomieju]

@oscar6echo I just merged a PR that should fix it. It will be available on canary release in a couple hours. Let me know if that fixes your problem.

[oscar6echo]

@bartlomieju thx I will try tomorrow morning.
But how to install the canary version given deno upgrade does not work behind a proxy yet ?

Normally I would do deno upgrade canary.
To install a specific version I do curl -fsSL https://deno.land/install.sh | sh -s v1.46.1 but it does not seem to work for canary ?

This is a bit of a catch 22 situation.

[bartlomieju]

@oscar6echo you should be able to do:

curl -fsSL https://deno.land/install.sh | sh -s v1.45.0
deno upgrade --canary --version bb26fef4946e16a9b9916f61786416523d173e8a
deno upgrade canary

Please keep in mind that we currently don't have newer canary versions, so you might have to wait a few more hours before some new PRs are landed.

I'll keep you informed. Let me re-open this issue for now.

[bartlomieju]

@oscar6echo that commit is now available on canary. By the time you try it another commit should be available as well.

[oscar6echo]

It does work fine now 👍
Screenshot below.

"This is a small step for deno devs but a giant leap for corp users" 🚀
This makes deno A LOT more friendly to use in this constrained env.

[bartlomieju]

Thanks, closing now then!

[oscar6echo]

For ref:
I see that the fix was released in v1.46.2