-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
no_proxy variable requires full domain names when multiple are specified #11449
Comments
I tried a bit more and found out that it has nothing to do with the full domain name. As soon as NO_PROXY contains more than one (comma-separated) entry, only the last one seems to be taken into account. |
@jasal82 This might play into it. I checked and figured out, that either the last one, or a FQDN works: # Specifying the matching domain last works
export no_proxy=".company.com,.company.net"
# But specifying the FQDN anywhere, works too
export no_proxy=".company.net,artifactory.company.net,.company.com" |
I believe this may have been a regression in libcurl (see curl/curl#9884). A new version is scheduled to come out in a few weeks, so I think this will need to wait for that. |
@weihanglo I'm not OP, but I also previously ran into this issue, and it seems to be fixed on nightly! tested nightly: output on nightly (exit code 0):
Output on stable:
|
Thank you so much for the feedback! Since it is verified that the bug no longer exists, I am going to close this as resolved. Thank you all! |
Problem
We have a company network that mirrors the rust registry internally (on artifactory). Also a company proxy is in place for connections outside of the company network. Thus this proxy is configured in all the common places.
The cargo mirror is available on artifactory.company.net
The proxy is defined via common variables, e.g. https_proxy.
We noticed that the no_proxy is only respected in certain situations:
In case of the non-working option we're stuck with errors like this:
With specifying the domain name completely
artifactory.company.net
vs.company.net
we have a solution, but it's unclear to us, why this behavior differs from other tools.Steps
No response
Possible Solution(s)
No response
Notes
Also we're using the nightly toolchain with sparse-registry.
Version
The text was updated successfully, but these errors were encountered: