From: Nelson Benitez Leon Date: Tue, 28 Feb 2012 14:57:33 GMT Subject: Re: [PATCH 2/3] http: try standard proxy env vars when http.proxy config option is not set Message-ID: <4F4CEB5D.5020808@seap.minhap.es> In-Reply-To: <878vjn8823.fsf@thomas.inf.ethz.ch> On 02/28/2012 01:19 PM, Thomas Rast wrote: > Nelson Benitez Leon writes: > >> + if (!curl_http_proxy) { >> + const char *env_proxy; >> + env_proxy = getenv("HTTP_PROXY"); >> + if (!env_proxy) { >> + env_proxy = getenv("http_proxy"); >> + } >> + if (env_proxy) { >> + curl_http_proxy = xstrdup(env_proxy); >> + } >> + } > > Admittedly I'm mostly clueless about curl, but while investigating the > NTLM login thing I noticed this bit in curl(1): > > ENVIRONMENT > The environment variables can be specified in lower case or upper > case. The lower case version has precedence. http_proxy is an > exception as it is only available in lower case. > > Which raises the questions: > > * Why is this needed? Does git's use of libcurl ignore http_proxy? [1] > seems to indicate that libcurl respects _proxy > automatically. It could not be needed, because, as you noted, curl already reads it, but then we will loose the feature on patch [3/3] because if $http_proxy has username but no password curl will not ask you for the password.. instead if we read it we could detect that, and ask for the password. As a minor note if we let curl to read it then patch [1/1] has to be changed to include CURLOPT_PROXYAUTH unconditionally (ie. out of the 'if (curl_http_proxy)'). I personally like the feature of not writing my password on $http_proxy at the cost of reading the env vars ourselves. > > * Why do you (need to?) support HTTP_PROXY when curl doesn't? I found somewhere documented HTTP_PROXY as well as http_proxy, but I've just checked wget[1] and also only supports http_proxy so I think we can discard it as is not widely used.. [1] http://www.gnu.org/software/wget/manual/html_node/Proxies.html > > > [1] http://curl.haxx.se/libcurl/c/libcurl-tutorial.html, "Environment Variables" >