-
-
Notifications
You must be signed in to change notification settings - Fork 4.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
http_proxy
is used for https://
URLs
#11876
Comments
I'm pretty sure we did this as some people only define http_proxy and most urls are these days https.. So indeed probably not a good idea to change at this point. Is there any way to set no_proxy to match https://* or smth perhaps? |
FWIW npm appears to work the same as curl/wget. It seems there is no way I can find to tell Composer to only use the proxy for HTTP, I've tried various things like this with no luck so IMO there is definitely a bug.
|
Yeah https_proxy being set empty is just seen as not being set, perhaps we could at least fix that, so you can explicitly set it empty to prevent it reusing http_proxy, as it shows you are aware https_proxy exists.. Would you like to try and send a PR for this? |
There is absolutely nothing wrong in doing this. Before the
This has nothing to do with the problem you are experiencing. In your example, using $this->fullProxy = [
"http" => "http://10.0.17.44:80",
"https" => "http://10.0.17.44:80",
] It uses this data to select the correct proxy for the scheme of the request url, so in your case it will select the same proxy url for both http and https requests. Furthermore, we set the proxy url in curl using the We designed it this way to handle the confusion over what each environment variable means and what it is expected to do. Essentially it doesn't actually matter what these variables are called: the important bit for Composer is the scheme of the proxy, due to limitations with streams and older curl versions.
This is the correct behaviour. If you change it then every proxy user who has not set an You obviously have an issue, but I don't think it is to do with Composer. I hope the above information helps you track it down. I've tested this with PHP-8.3.4, which uses the latest curl version 8.6.0 and it still works as intended:
|
Thanks for the detailed response @johnstevenson. Could you please explain how I can configure Composer to use a proxy for HTTP and not HTTPS? I have a proxy which purposefully does not permit the use of HTTP CONNECT.
So Composer works differently to curl and a lot of other tools/libraries? It would definitely worthwhile documenting this. |
Thanks for explaining your proxy config. Is there a reason for not using HTTP_CONNECT?
Here is the documentation from 2012: If you are using composer from behind an HTTP proxy, you can use the standard
`http_proxy` or `HTTP_PROXY` env vars. Simply set it to the URL of your proxy.
Many operating systems already set this variable for you.
Using `http_proxy` (lowercased) or even defining both might be preferrable since
some tools like git or curl will only use the lower-cased `http_proxy` version. And it hasn't changed much since: https://getcomposer.org/doc/03-cli.md#http-proxy-or-http-proxy
By default, Composer uses https (unless config @Seldaek The landscape seems to have changed a little since 2020, in terms of specific https_proxy usage. Back then, C# and dotnet preferred http_proxy, but from a quick trawl through the dotnet repos they nearly all require https_proxy for https connections. Ruby is still sticking to http_proxy, though. It might now make sense to follow suit and exactly match curl, particularly as they now support CIDR ranges in no_proxy, which they didn't in 2020. Perhaps we could show a warning for a period of time that https_proxy will be required after a certain date? |
Yes I would tend to agree, but it's a bit problematic as it will risk causing breakage for people not defining HTTPS_PROXY. I'm not sure how we can best handle this, maybe support setting an empty HTTPS_PROXY first - without overwriting it with the http_proxy value - so that we enable that use case (assuming curl and others handle that well). Then we could warn if https_proxy is unset and http_proxy is set, but keep the "copy" mechanism in place for now, and then eventually remove that? |
Quite simply nginx doesn't support it.
I know. My use case is in a CI environment we started setting
Ruby uses the scheme to determine which proxy to use, although the docs are not very clear on the matter. require 'uri'
['http://example.com/', 'https://example.com/'].each { |url|
print url, " - ", URI.parse(url).find_proxy, "\n"
}
|
Ah, thanks for clarifying that.
That's because nginx is a reverse proxy, not a forward proxy. The purpose of the http_proxy environment variables is to inform tools that a forward proxy is being used and to act accordingly. |
#11915 prepares the terrain to get this fixed in 2.8. |
👍 Brilliant, thanks both. |
After configuring the
http_proxy
environment variable to proxy plain HTTP requests Composer starts failing because it uses the proxy server for encrypted HTTP requests. Whilst I appreciate there is no defined standard, I'm pretty sure Composer is deviating from the convention here but I could be wrong.Output of
composer diagnose
:curl/wget both seem to operate as I expect:
I've tracked the problem down to a single line of code:
composer/src/Composer/Util/Http/ProxyHelper.php
Line 51 in 66acb84
However it occurs to me that people might be relying on the behaviour so fixing it might not be as straightforward as removing that line.
References: https://about.gitlab.com/blog/2021/01/27/we-need-to-talk-no-proxy/
The text was updated successfully, but these errors were encountered: