Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Match libcurl lowercase proxy environment variable behaviour #503

Merged
merged 1 commit into from
Nov 2, 2021

Conversation

mjcheetham
Copy link
Collaborator

libcurl supports multiple different environment variables1 to configure proxy behaviour: http_proxy, https_proxy, all_proxy, and no_proxy.

Unlike most other environment variables these proxy envars are normally lowercase, not uppercase. This convention was set by libwww back in the early 1990s. When libcurl was first released however, it was not aware of this schism and only implemented checks for uppercase variants of these envars: HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, and NO_PROXY.

In time, libcurl learned to also read the lowercase variants, and gives them precedence over the uppercase forms (since the former are quasi-standards).

However, to further complicate the matter, libcurl no longer reads the uppercase HTTP_PROXY variable specifically. This change was made to address a security concern with some CGI webservers2.

The problem is that today GCM only reads the uppercase variants of the environment variables! This is inconsistent with libcurl, and therefore Git's behaviour (that we aim to be consistent/co-operative with).

We change GCM's behaviour to match that of libcurl/Git in that the lowercase proxy envars are preferred to the uppercase ones, and the uppercase HTTP_PROXY variable is ignored.

Dropping support for the HTTP_PROXY uppercase envar is technically a breaking change, but if the user had only set this uppercase envar then Git would not be proxying the actual remote calls, only GCM, which is most likely not what the user wanted.

  1. https://everything.curl.dev/usingcurl/proxies#proxy-environment-variables
  2. https://everything.curl.dev/usingcurl/proxies#http_proxy-in-lower-case-only

libcurl supports multiple different environment variables [1] to
configure proxy behaviour: http_proxy, https_proxy, all_proxy, and
no_proxy.

Unlike most other environment variables these proxy envars are normally
_lowercase_, not uppercase. This convention was set by libwww back in
the early 1990s. When libcurl was first released however, it was not
aware of this schism and only implemented checks for uppercase variants
of these envars: HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, and NO_PROXY.

In time, libcurl learned to also read the lowercase variants, and gives
them precedence over the uppercase forms (since the former are quasi-
standards).

However, to further complicate the matter, libcurl no longer reads the
uppercase HTTP_PROXY variable specifically. This change was made to
address a security concern with some CGI webservers [2].

The problem is that today GCM only reads the uppercase variants of the
environment variables! This is inconsistent with libcurl, and therefore
Git's behaviour (that we aim to be consistent/co-operative with).

We change GCM's behaviour to match that of libcurl/Git in that the
lowercase proxy envars are preferred to the uppercase ones, and the
uppercase HTTP_PROXY variable is ignored.

Dropping support for the HTTP_PROXY uppercase envar is technically a
breaking change, but if the user had only set this uppercase envar then
Git would not be proxying the actual remote calls, only GCM, which is
most likely not what the user wanted.

[1] https://everything.curl.dev/usingcurl/proxies#proxy-environment-variables
[2] https://everything.curl.dev/usingcurl/proxies#http_proxy-in-lower-case-only
@mjcheetham mjcheetham marked this pull request as ready for review November 2, 2021 10:33
@mjcheetham mjcheetham merged commit 90a8d6d into git-ecosystem:main Nov 2, 2021
@mjcheetham mjcheetham deleted the curl-envars branch November 2, 2021 10:43
This was referenced Nov 15, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants