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

Jeff King [off-list ref] writes:

On Sat, Mar 03, 2012 at 03:50:53PM +0100, Clemens Buchacher wrote:

quoted

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.

On Sat, Mar 03, 2012 at 02:22:39PM -0800, Junio C Hamano wrote:

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.?

I actually prefer the current behavior, which is to configure only one
proxy for all protocols. I have not seen a setup where HTTP and HTTPS
are routed through different proxies before. But if this is really
needed, one has the option to use the environment variable, or
remote.<name>.proxy.

I suggest instead that we map curl's CURLOPT_PROXY to core.proxy.  That
would also fit well with the remote.<name>.proxy scheme.