Re: [PATCH] http.proxy: also mention https_proxy and all_proxy

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 3, 2012, 22:22 UTC
Message-ID: <7v399p72a8.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20120303174252.GC28602@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 11 quoted lines

> On Sat, Mar 03, 2012 at 03:50:53PM +0100, Clemens Buchacher wrote:
>
>> The current wording of the http.proxy documentation suggests that
>> http_proxy is somehow equivalent to http.proxy. However, while
>> http.proxy (by the means of curl's CURLOPT_PROXY option) overrides the
>> proxy for both HTTP and HTTPS protocols, the http_proxy environment
>> variable is used only for HTTP. But since the docs mention only
>> http_proxy, a user might expect it to apply to all HTTP-like protocols.
>
> Hmm, I didn't know that. This certainly adds an interesting twist to the
> patch in a nearby thread to start reading http_proxy ourselves.

Yeah, I too had an "Ahhhh" moment.

I recall that I was frustrated more than 10 years ago when I had to point at our company proxy with many *_proxy variables in my .login and ended up writing a shell script (and placed it under source control) that generates dot files from a single source (which of course is under source control).

The manual page for curl seems to say that they have separate HTTPS_PROXY and friends all in caps, and http_proxy is left lowercase for historical reasons [*1*].

As to the way forward, I suspect that http.proxy was a mistake to begin with, considering the structure of namespace our configuration variables fit in. Shouldn't they be proxy.http, proxy.https, etc.?

And if we were to map curl's HTTPS_PROXY to proxy.https to fix this namespace gotha, we could treat http.proxy as a historical mistake, and introduce proxy.http as what matches curl's http_proxy.

Then the change proposed in the nearby thread can notice http_proxy and behave as if proxy.http is set, which would only affect http but not https. When http.proxy is set, we still let it affect anything curl handles.

[Footnote]

*1* Come to think of it, the alleged Mac OS X breakage I mentined may merely be a second-hand rumor of a misdiagnosed user error---the user might have been trying to reach https:// resource with only http_proxy set.