[PATCH 2/3] http: try standard proxy env vars when http.proxy config option is not set

[PATCH 2/3] http: try standard proxy env vars when http.proxy config option is not set

[Nelson Benitez Leon]

Signed-off-by: Nelson Benitez Leon <nbenitezl@gmail.com>
---
 http.c |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/http.c b/http.c
index 8ac8eb6..79cbe50 100644
--- a/http.c
+++ b/http.c
@@ -295,6 +295,16 @@ static CURL *get_curl_handle(void)
 	if (curl_ftp_no_epsv)
 		curl_easy_setopt(result, CURLOPT_FTP_USE_EPSV, 0);
 
+	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);
+		}
+	}
 	if (curl_http_proxy) {
 		curl_easy_setopt(result, CURLOPT_PROXY, curl_http_proxy);
 		curl_easy_setopt(result, CURLOPT_PROXYAUTH, CURLAUTH_ANY);
-- 
1.7.7.6

Re: [PATCH 2/3] http: try standard proxy env vars when http.proxy config option is not set

[Thomas Rast]

Nelson Benitez Leon <nelsonjesus.benitez@seap.minhap.es> 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 <protocol>_proxy
  automatically.

* Why do you (need to?) support HTTP_PROXY when curl doesn't?


[1] http://curl.haxx.se/libcurl/c/libcurl-tutorial.html, "Environment Variables"

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

Re: [PATCH 2/3] http: try standard proxy env vars when http.proxy config option is not set

[Nelson Benitez Leon]

On 02/28/2012 01:19 PM, Thomas Rast wrote:
> Nelson Benitez Leon <nelsonjesus.benitez@seap.minhap.es> 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 <protocol>_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"
> 

Re: [PATCH 2/3] http: try standard proxy env vars when http.proxy config option is not set

[Thomas Rast]

Nelson Benitez Leon <nelsonjesus.benitez@seap.minhap.es> writes:

> On 02/28/2012 01:19 PM, Thomas Rast wrote:
>> 
>> * Why is this needed?  Does git's use of libcurl ignore http_proxy?  [1]
>>   seems to indicate that libcurl respects <protocol>_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. 

Ok.  An explanation along these lines should definitely go into the
commit message!

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

Re: [PATCH 2/3] http: try standard proxy env vars when http.proxy config option is not set

[Junio C Hamano]

Thomas Rast <trast@inf.ethz.ch> writes:

> Which raises the questions:
>
> * Why is this needed?  Does git's use of libcurl ignore http_proxy?  [1]
>   seems to indicate that libcurl respects <protocol>_proxy
>   automatically.
>
> * Why do you (need to?) support HTTP_PROXY when curl doesn't?

Let me add a third bullet point.

I've heard rumors that libcurl on some versions/installations of Mac OS X
deliberately ignores the environment. For those who agree with Apple, it
would be a regression if we suddenly start the environment ourselves and
using it.

Re: [PATCH 2/3] http: try standard proxy env vars when http.proxy config option is not set

[Nelson Benitez Leon]

On 02/28/2012 08:24 PM, Junio C Hamano wrote:
> Thomas Rast <trast@inf.ethz.ch> writes:
> 
>> Which raises the questions:
>>
>> * Why is this needed?  Does git's use of libcurl ignore http_proxy?  [1]
>>   seems to indicate that libcurl respects <protocol>_proxy
>>   automatically.
>>
>> * Why do you (need to?) support HTTP_PROXY when curl doesn't?
> 
> Let me add a third bullet point.
> 
> I've heard rumors that libcurl on some versions/installations of Mac OS X
> deliberately ignores the environment. For those who agree with Apple, it
> would be a regression if we suddenly start the environment ourselves and
> using it.

Hi Junio, what did you mean by "we start the environment and using it"?
I didn't understand what you mean there..

Re: [PATCH 2/3] http: try standard proxy env vars when http.proxy config option is not set

[Junio C Hamano]

Nelson Benitez Leon <nelsonjesus.benitez@seap.minhap.es> writes:

> On 02/28/2012 08:24 PM, Junio C Hamano wrote:
>
>> I've heard rumors that libcurl on some versions/installations of Mac OS X
>> deliberately ignores the environment. For those who agree with Apple, it
>> would be a regression if we suddenly start the environment ourselves and
>> using it.
>
> Hi Junio, what did you mean by "we start the environment and using it"?
> I didn't understand what you mean there..

The reason you didn't understand is because the statement does not parse
X-<.  Thanks for pointing it out.

What I meant was that on these platforms, allegedly (note that I do not
have a first-hand experience with them), user's http_proxy environment
setting did not affect libcurl based applications and that is a deliberate
platform decision to give precedence to proxy settings the platform has
elsewhere.  The users who agree with this platform decision are happily
using the proxy settings stored elsewhere in the platform with git, but
may have http_proxy environment pointing at a proxy that they do not want
to use for git.

If we suddenly start reading from http_proxy environment ourselves and
explicitly telling libcurl to use the proxy specified, it will change the
behaviour for these users, i.e. a regression.

Re: [PATCH 2/3] http: try standard proxy env vars when http.proxy config option is not set

[Nelson Benitez Leon]

On 02/29/2012 07:15 PM, Junio C Hamano wrote:
> Nelson Benitez Leon <nelsonjesus.benitez@seap.minhap.es> writes:
> 
>> On 02/28/2012 08:24 PM, Junio C Hamano wrote:
>>
>>> I've heard rumors that libcurl on some versions/installations of Mac OS X
>>> deliberately ignores the environment. For those who agree with Apple, it
>>> would be a regression if we suddenly start the environment ourselves and
>>> using it.
>>
>> Hi Junio, what did you mean by "we start the environment and using it"?
>> I didn't understand what you mean there..
> 
> The reason you didn't understand is because the statement does not parse
> X-<.  Thanks for pointing it out.
> 
> What I meant was that on these platforms, allegedly (note that I do not
> have a first-hand experience with them), user's http_proxy environment
> setting did not affect libcurl based applications and that is a deliberate
> platform decision to give precedence to proxy settings the platform has
> elsewhere.  The users who agree with this platform decision are happily

I googled for that but didn't find any info, anyway if that's true did they 
do this by 1) removing http_proxy from environment or by 2) patching
libcurl not to read them ? if it's the first case, we are safe as they will 
also remove the vars and we won't read them, if it's second case, it's silly
on their part as any other console program will be reading env vars as they
would need to patch every program..

The normal thing os's do (as gnome used to do) is to automatically set the
http_proxy env vars when you set a proxy on the GUI..

> using the proxy settings stored elsewhere in the platform with git, but
> may have http_proxy environment pointing at a proxy that they do not want
> to use for git.
> 
> If we suddenly start reading from http_proxy environment ourselves and
> explicitly telling libcurl to use the proxy specified, it will change the
> behaviour for these users, i.e. a regression.

Re: [PATCH 2/3] http: try standard proxy env vars when http.proxy config option is not set

[Daniel Stenberg]

On Tue, 28 Feb 2012, Junio C Hamano wrote:

>> * Why do you (need to?) support HTTP_PROXY when curl doesn't?
>
> Let me add a third bullet point.
>
> I've heard rumors that libcurl on some versions/installations of Mac OS X 
> deliberately ignores the environment. For those who agree with Apple, it 
> would be a regression if we suddenly start the environment ourselves and 
> using it.

I can also add that in libcurl we completely deliberately do not support 
"HTTP_PROXY" (using all upper case) for a quite simple and boring reason:

The (very old) CGI interface that web servers use(d) to invoke programs 
server-side passes on header values in environment variables named 
"HTTP_[header]". So if you send a request to a server that starts a CGI script 
and use a request header named Proxy: in that request, that header will be 
passed to the CGI script using the environment variable "HTTP_PROXY" ...

-- 

  / daniel.haxx.se

Re: [PATCH 2/3] http: try standard proxy env vars when http.proxy config option is not set

[Jeff King]

On Tue, Feb 28, 2012 at 01:54:34PM +0100, Nelson Benitez Leon wrote:

> diff --git a/http.c b/http.c
> index 8ac8eb6..79cbe50 100644
> --- a/http.c
> +++ b/http.c
> @@ -295,6 +295,16 @@ static CURL *get_curl_handle(void)
>  	if (curl_ftp_no_epsv)
>  		curl_easy_setopt(result, CURLOPT_FTP_USE_EPSV, 0);
>  
> +	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);
> +		}
> +	}

Usually we would prefer environment variables to config. So that:

  $ git config http.proxy foo
  $ HTTP_PROXY=bar git fetch

would use "bar" as the proxy, not "foo". But your code above would
prefer "foo", right?

>From reading Thomas's messages, I think there is a slight complication
in that right now curl is respecting $http_proxy, and it is probably
letting git's http.proxy overwrite (though I didn't check). If that is
the case, then that is IMHO a bug that should be fixed. So the rationale
for this patch would be three-fold:

  1. Support HTTP_PROXY, which curl does not accept.

  2. Fix the precedence of environment variables over config.

  3. By handling the proxy variables ourselves, we have more flexibility
     in handling the authentication.

-Peff

Re: [PATCH 2/3] http: try standard proxy env vars when http.proxy config option is not set

[Sam Vilain]

On 2/28/12 11:15 AM, Jeff King wrote:
> Usually we would prefer environment variables to config. So that:
>
>    $ git config http.proxy foo
>    $ HTTP_PROXY=bar git fetch
>
> would use "bar" as the proxy, not "foo". But your code above would
> prefer "foo", right?

Apparently I'm the author of the http.proxy feature, though I barely 
remember what problem I was actually solving at the time.  At the time I 
justified it on the grounds that a user might want to use a different 
proxy for git and/or a particular remote.  The "http_proxy" environment 
variable is likely to be a global system default, or perhaps a desktop 
setting, and therefore I'd say probably less and not more specific than 
a git configuration variable.

As to this matter of "HTTP_PROXY", I'm not sure about whether that helps 
or confuses matters to support.  I must admit I'm still confused by the 
motivation of this patch series.

Sam

Re: [PATCH 2/3] http: try standard proxy env vars when http.proxy config option is not set

[Jeff King]

On Tue, Feb 28, 2012 at 11:27:41AM -0800, Sam Vilain wrote:

> On 2/28/12 11:15 AM, Jeff King wrote:
> >Usually we would prefer environment variables to config. So that:
> >
> >   $ git config http.proxy foo
> >   $ HTTP_PROXY=bar git fetch
> >
> >would use "bar" as the proxy, not "foo". But your code above would
> >prefer "foo", right?
> 
> Apparently I'm the author of the http.proxy feature, though I barely
> remember what problem I was actually solving at the time.  At the
> time I justified it on the grounds that a user might want to use a
> different proxy for git and/or a particular remote.  The "http_proxy"
> environment variable is likely to be a global system default, or
> perhaps a desktop setting, and therefore I'd say probably less and
> not more specific than a git configuration variable.

Good point. We sometimes follow this order:

  1. git-specific environment variables (i.e., $GIT_HTTP_PROXY, if
     it existed)
  2. git config files (i.e., http.proxy)
  3. generic system environment (i.e., $http_proxy).

So thinking about it that way, the original patch makes more sense.

-Peff

Re: [PATCH 2/3] http: try standard proxy env vars when http.proxy config option is not set

[Matthieu Moy]

Jeff King <peff@peff.net> writes:

> Good point. We sometimes follow this order:
>
>   1. git-specific environment variables (i.e., $GIT_HTTP_PROXY, if
>      it existed)
>   2. git config files (i.e., http.proxy)
>   3. generic system environment (i.e., $http_proxy).

Yes, just like $EDITOR << core.editor << $GIT_EDITOR.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: [PATCH 2/3] http: try standard proxy env vars when http.proxy config option is not set

[Nelson Benitez Leon]

On 02/28/2012 08:34 PM, Jeff King wrote:
> On Tue, Feb 28, 2012 at 11:27:41AM -0800, Sam Vilain wrote:
> 
>> On 2/28/12 11:15 AM, Jeff King wrote:
>>> Usually we would prefer environment variables to config. So that:
>>>
>>>   $ git config http.proxy foo
>>>   $ HTTP_PROXY=bar git fetch
>>>
>>> would use "bar" as the proxy, not "foo". But your code above would
>>> prefer "foo", right?
>>
>> Apparently I'm the author of the http.proxy feature, though I barely
>> [snip]
> 
> Good point. We sometimes follow this order:
> 
>   1. git-specific environment variables (i.e., $GIT_HTTP_PROXY, if
>      it existed)
>   2. git config files (i.e., http.proxy)
>   3. generic system environment (i.e., $http_proxy).
> 
> So thinking about it that way, the original patch makes more sense.

So, in PATCH 2/3, apart from expanding the commit message.. do we want
to support HTTP_PROXY or only http_proxy ? HTTP_PROXY seems to not be
very used by existent programs, but support it it's only a gentenv call..

Re: [PATCH 2/3] http: try standard proxy env vars when http.proxy config option is not set

[Jeff King]

On Wed, Feb 29, 2012 at 11:46:03AM +0100, Nelson Benitez Leon wrote:

> > Good point. We sometimes follow this order:
> > 
> >   1. git-specific environment variables (i.e., $GIT_HTTP_PROXY, if
> >      it existed)
> >   2. git config files (i.e., http.proxy)
> >   3. generic system environment (i.e., $http_proxy).
> > 
> > So thinking about it that way, the original patch makes more sense.
> 
> So, in PATCH 2/3, apart from expanding the commit message.. do we want
> to support HTTP_PROXY or only http_proxy ? HTTP_PROXY seems to not be
> very used by existent programs, but support it it's only a gentenv call..

If HTTP_PROXY is not in wide use, I don't see a reason to support it.
And I take back what I said about environment precedence, based on the
discussion. Also, I don't think there is a need to strdup the results of
getenv here, is there? So I think the code you want is just:

  if (!curl_http_proxy)
          curl_http_proxy = getenv("http_proxy");

and the justification for the commit message is that we need to know the
proxy value outside of curl, because the next patch will do some
extra processing on the value.

-Peff

Re: [PATCH 2/3] http: try standard proxy env vars when http.proxy config option is not set

[Nelson Benitez Leon]

On 02/29/2012 10:08 PM, Jeff King wrote:
> On Wed, Feb 29, 2012 at 11:46:03AM +0100, Nelson Benitez Leon wrote:
> 
>>> Good point. We sometimes follow this order:
>>>
>>>   1. git-specific environment variables (i.e., $GIT_HTTP_PROXY, if
>>>      it existed)
>>>   2. git config files (i.e., http.proxy)
>>>   3. generic system environment (i.e., $http_proxy).
>>>
>>> So thinking about it that way, the original patch makes more sense.
>>
>> So, in PATCH 2/3, apart from expanding the commit message.. do we want
>> to support HTTP_PROXY or only http_proxy ? HTTP_PROXY seems to not be
>> very used by existent programs, but support it it's only a gentenv call..
> 
> If HTTP_PROXY is not in wide use, I don't see a reason to support it.

Ok

> And I take back what I said about environment precedence, based on the
> discussion. Also, I don't think there is a need to strdup the results of
> getenv here, is there? So I think the code you want is just:
> 
>   if (!curl_http_proxy)
>           curl_http_proxy = getenv("http_proxy");

but curl_http_proxy gets freed in http_cleanup as follows:

free((void *)curl_http_proxy);

Is it ok to free strings returned by getenv() ? I thought nope, so I
used strdup which existent code was already using..
> 
> and the justification for the commit message is that we need to know the
> proxy value outside of curl, because the next patch will do some
> extra processing on the value.
> 
> -Peff
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] http: try standard proxy env vars when http.proxy config option is not set

[Jeff King]

On Thu, Mar 01, 2012 at 10:57:03AM +0100, Nelson Benitez Leon wrote:

> > And I take back what I said about environment precedence, based on the
> > discussion. Also, I don't think there is a need to strdup the results of
> > getenv here, is there? So I think the code you want is just:
> > 
> >   if (!curl_http_proxy)
> >           curl_http_proxy = getenv("http_proxy");
> 
> but curl_http_proxy gets freed in http_cleanup as follows:
> 
> free((void *)curl_http_proxy);
> 
> Is it ok to free strings returned by getenv() ? I thought nope, so I
> used strdup which existent code was already using..

Ah, you're right. I was worried more about lifetime issues (i.e., would
the string still be valid) and didn't check to see whether we freed it
(and we should, because if it comes from config, then it will be
allocated). So yes, you should duplicate it.

-Peff

Re: [PATCH 2/3] http: try standard proxy env vars when http.proxy config option is not set

[James Cloos]

Please include a way, eg via ~/.gitconfig, to ignore any http_proxy in
the environment and connect directly.

The proxy might exist solely to aggregate a cache and not as a necessary
link to the outside; forcing git to use it in such cases is more harmful
than beneficial.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: [PATCH 2/3] http: try standard proxy env vars when http.proxy config option is not set

[Junio C Hamano]

James Cloos <cloos@jhcloos.com> writes:

> Please include a way, eg via ~/.gitconfig, to ignore any http_proxy in
> the environment and connect directly.

Hrm.

I think without this patch series, the "NO_PROXY" environment
variable is honored by the curl library when it uses http_proxy
to make the decision. If this patch (or a future reroll of it) fails
to do the same, it would be a regression.

Nelson, do you agree?

Re: [PATCH 2/3] http: try standard proxy env vars when http.proxy config option is not set

[Nelson Benitez Leon]

On 03/11/2012 08:12 PM, Junio C Hamano wrote:
> James Cloos <cloos@jhcloos.com> writes:
> 
>> Please include a way, eg via ~/.gitconfig, to ignore any http_proxy in
>> the environment and connect directly.
> 
> Hrm.
> 
> I think without this patch series, the "NO_PROXY" environment
> variable is honored by the curl library when it uses http_proxy
> to make the decision. If this patch (or a future reroll of it) fails
> to do the same, it would be a regression.
> 
> Nelson, do you agree?

I agree, so I would need to handle $no_proxy in the patch-set, will look
into that.

Re: [PATCH 2/3] http: try standard proxy env vars when http.proxy config option is not set

[Junio C Hamano]

Nelson Benitez Leon <nelsonjesus.benitez@seap.minhap.es> writes:

> On 03/11/2012 08:12 PM, Junio C Hamano wrote:
>> James Cloos <cloos@jhcloos.com> writes:
>> 
>>> Please include a way, eg via ~/.gitconfig, to ignore any http_proxy in
>>> the environment and connect directly.
>> 
>> Hrm.
>> 
>> I think without this patch series, the "NO_PROXY" environment
>> variable is honored by the curl library when it uses http_proxy
>> to make the decision. If this patch (or a future reroll of it) fails
>> to do the same, it would be a regression.
>> 
>> Nelson, do you agree?
>
> I agree, so I would need to handle $no_proxy in the patch-set, will look
> into that.

Are you sure $no_proxy is spelled in lowercase?  man curl(1) seems to
indicate otherwise.

Re: [PATCH 2/3] http: try standard proxy env vars when http.proxy config option is not set

[Nelson Benitez Leon]

On 03/14/2012 05:36 AM, Junio C Hamano wrote:
> Nelson Benitez Leon <nelsonjesus.benitez@seap.minhap.es> writes:
> 
>> On 03/11/2012 08:12 PM, Junio C Hamano wrote:
>>> James Cloos <cloos@jhcloos.com> writes:
>>>
>>>> Please include a way, eg via ~/.gitconfig, to ignore any http_proxy in
>>>> the environment and connect directly.
>>>
>>> Hrm.
>>>
>>> I think without this patch series, the "NO_PROXY" environment
>>> variable is honored by the curl library when it uses http_proxy
>>> to make the decision. If this patch (or a future reroll of it) fails
>>> to do the same, it would be a regression.
>>>
>>> Nelson, do you agree?
>>
>> I agree, so I would need to handle $no_proxy in the patch-set, will look
>> into that.
> 
> Are you sure $no_proxy is spelled in lowercase?  man curl(1) seems to
> indicate otherwise.

Instead here[1] in section "Environment Variables" it's spelled lowercase,
and given that cURL reads $http_proxy only in lowercase I think it does
the same for $no_proxy.

[1] http://curl.haxx.se/libcurl/c/libcurl-tutorial.html

Re: [PATCH 2/3] http: try standard proxy env vars when http.proxy config option is not set

[Junio C Hamano]

Nelson Benitez Leon <nelsonjesus.benitez@seap.minhap.es> writes:

> On 03/14/2012 05:36 AM, Junio C Hamano wrote:
>
>> Are you sure $no_proxy is spelled in lowercase?  man curl(1) seems to
>> indicate otherwise.
>
> Instead here[1] in section "Environment Variables" it's spelled lowercase,
> and given that cURL reads $http_proxy only in lowercase I think it does
> the same for $no_proxy.

Don't think, but read ;-).  Quoting from man 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.

Re: [PATCH 2/3] http: try standard proxy env vars when http.proxy config option is not set

[Nelson Benitez Leon]

On 03/14/2012 09:41 PM, Junio C Hamano wrote:
> Nelson Benitez Leon <nelsonjesus.benitez@seap.minhap.es> writes:
> 
>> On 03/14/2012 05:36 AM, Junio C Hamano wrote:
>>
>>> Are you sure $no_proxy is spelled in lowercase?  man curl(1) seems to
>>> indicate otherwise.
>>
>> Instead here[1] in section "Environment Variables" it's spelled lowercase,
>> and given that cURL reads $http_proxy only in lowercase I think it does
>> the same for $no_proxy.
> 
> Don't think, but read ;-).  Quoting from man 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.
> 

Ok, good advice nonetheless :-), so will send a new 1/5 patch that also
reads $NO_PROXY.