threads / patch / 29771

patch, 3 partshttp: try standard proxy env vars when http.proxy config option is not set

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

## tl;dr

24 messages between Feb 28, 2012 and Mar 15, 2012. Diffs are folded; open one to read it.

replies: 23people: 8as markdown or json

Nelson Benitez Leon· Feb 28, 2012, 12:54 UTC · lore
Signed-off-by: Nelson Benitez Leon <nbenitezl@gmail.com>
---
 http.c |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)
Show changes to http.c +10 −0
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
Thomas Rast· Feb 28, 2012, 12:19 UTC · re: Nelson Benitez Leon · lore

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

Nelson Benitez Leon <nelsonjesus.benitez@seap.minhap.es> writes:
Show 10 quoted lines
> +	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
Nelson Benitez Leon· Feb 28, 2012, 14:57 UTC · re: Thomas Rast · lore

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

On 02/28/2012 01:19 PM, Thomas Rast wrote:
Show 26 quoted lines
> 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"
> 
Thomas Rast· Feb 28, 2012, 14:34 UTC · re: Nelson Benitez Leon · lore

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

Nelson Benitez Leon <nelsonjesus.benitez@seap.minhap.es> writes:
Show 10 quoted lines
> 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
Junio C Hamano· Feb 28, 2012, 19:24 UTC · re: Thomas Rast · lore

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

Thomas Rast <trast@inf.ethz.ch> writes:
Show 7 quoted lines
> 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.

Nelson Benitez Leon· Feb 29, 2012, 10:38 UTC · re: Junio C Hamano · lore

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

On 02/28/2012 08:24 PM, Junio C Hamano wrote:
Show 16 quoted lines
> 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..

Junio C Hamano· Feb 29, 2012, 18:15 UTC · re: Nelson Benitez Leon · lore

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

Nelson Benitez Leon <nelsonjesus.benitez@seap.minhap.es> writes:
Show 9 quoted lines
> 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.

Nelson Benitez Leon· Mar 1, 2012, 10:18 UTC · re: Junio C Hamano · lore

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

On 02/29/2012 07:15 PM, Junio C Hamano wrote:
Show 20 quoted lines
> 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..

Show 7 quoted lines
> 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.
Daniel Stenberg· Mar 4, 2012, 19:19 UTC · re: Junio C Hamano · lore

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

On Tue, 28 Feb 2012, Junio C Hamano wrote:
Show 8 quoted lines
>> * 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
Jeff King· Feb 28, 2012, 19:15 UTC · re: Nelson Benitez Leon · lore

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

On Tue, Feb 28, 2012 at 01:54:34PM +0100, Nelson Benitez Leon wrote:
Show 18 quoted lines
> 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
Sam Vilain· Feb 28, 2012, 19:27 UTC · re: Jeff King · lore

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

On 2/28/12 11:15 AM, Jeff King wrote:
Show 7 quoted lines
> 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
Jeff King· Feb 28, 2012, 19:34 UTC · re: Sam Vilain · lore

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

On Tue, Feb 28, 2012 at 11:27:41AM -0800, Sam Vilain wrote:
Show 16 quoted lines
> 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
Matthieu Moy· Feb 29, 2012, 09:55 UTC · re: Jeff King · lore

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

Jeff King <peff@peff.net> writes:
Show 6 quoted lines
> 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/
Nelson Benitez Leon· Feb 29, 2012, 10:46 UTC · re: Jeff King · lore

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

On 02/28/2012 08:34 PM, Jeff King wrote:
Show 22 quoted lines
> 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..

Jeff King· Feb 29, 2012, 21:08 UTC · re: Nelson Benitez Leon · lore

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

On Wed, Feb 29, 2012 at 11:46:03AM +0100, Nelson Benitez Leon wrote:
Show 12 quoted lines
> > 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
Nelson Benitez Leon· Mar 1, 2012, 09:57 UTC · re: Jeff King · lore

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

On 02/29/2012 10:08 PM, Jeff King wrote:
Show 16 quoted lines
> 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
Show 6 quoted lines
> 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..

Show 10 quoted lines
> 
> 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
Jeff King· Mar 1, 2012, 09:10 UTC · re: Nelson Benitez Leon · lore

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

On Thu, Mar 01, 2012 at 10:57:03AM +0100, Nelson Benitez Leon wrote:
Show 13 quoted lines
> > 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
James Cloos· Mar 11, 2012, 16:56 UTC · re: Nelson Benitez Leon · lore

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

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
Junio C Hamano· Mar 11, 2012, 19:12 UTC · re: James Cloos · lore

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

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?
Nelson Benitez Leon· Mar 13, 2012, 10:22 UTC · re: Junio C Hamano · lore

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

On 03/11/2012 08:12 PM, Junio C Hamano wrote:
Show 13 quoted lines
> 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.

Junio C Hamano· Mar 14, 2012, 04:36 UTC · re: Nelson Benitez Leon · lore

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

Nelson Benitez Leon <nelsonjesus.benitez@seap.minhap.es> writes:
Show 17 quoted lines
> 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.

Nelson Benitez Leon· Mar 14, 2012, 09:54 UTC · re: Junio C Hamano · lore

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

On 03/14/2012 05:36 AM, Junio C Hamano wrote:
Show 22 quoted lines
> 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
Junio C Hamano· Mar 14, 2012, 20:41 UTC · re: Nelson Benitez Leon · lore

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

Nelson Benitez Leon <nelsonjesus.benitez@seap.minhap.es> writes:
Show 8 quoted lines
> 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.
Nelson Benitez Leon· Mar 15, 2012, 09:38 UTC · re: Junio C Hamano · lore

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

On 03/14/2012 09:41 PM, Junio C Hamano wrote:
Show 19 quoted lines
> 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.

← back to recent threads