http: accept https:// proxies again

[dscho]

Cc: Aliwoto aminnimaj@gmail.com

[dscho]

/submit

[gitgitgadget]

Submitted as pull.2161.git.1782580676734.gitgitgadget@gmail.com

To fetch this version into FETCH_HEAD:

git fetch https://github.com/gitgitgadget/git/ pr-2161/dscho/fix-bug-in-validate-proxy-url-scheme-v1

To fetch this version to local tag pr-2161/dscho/fix-bug-in-validate-proxy-url-scheme-v1:

git fetch --no-tags https://github.com/gitgitgadget/git/ tag pr-2161/dscho/fix-bug-in-validate-proxy-url-scheme-v1

[gitgitgadget]

This branch is now known as js/http-https-proxy-fix.

[gitgitgadget]

This patch series was integrated into seen via git@1274757.

[gitgitgadget]

This patch series was integrated into master via git@1274757.

[gitgitgadget]

This patch series was integrated into next via git@1274757.

[gitgitgadget]

Congratulations! 🎉 Your patch series was merged into upstream via 1274757.

Note: this pull request will show as "Closed" rather than "Merged" because the merge happened in the upstream repository, not on GitHub. This is expected — your contribution has been accepted!

[gitgitgadget]

Junio C Hamano wrote on the Git mailing list (how to reply to this email):

"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
writes:

>  http.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/http.c b/http.c
> index 8e5a4d8bcf..8c0f831365 100644
> --- a/http.c
> +++ b/http.c
> @@ -802,6 +802,8 @@ static int set_curl_proxy_type(CURL *result, const char *protocol)
>  		if (has_proxy_cert_password())
>  			curl_easy_setopt(result, CURLOPT_PROXY_KEYPASSWD,
>  					 proxy_cert_auth.password);
> +
> +		return 0;
>  	}
>  
>  	return -1;

That lack of "return 0" is so glaringly obvious when you point it
out like this patch does, and it is surprising it has been missed
initially.

From this function nothing returns an error anymore, and looking at
the preimage of 663d7abe (http: reject unsupported proxy URL
schemes, 2026-05-05) that is the source of the bug, the original did
not do anything when the corresponding code did not find and set any
proxy settings, either.

So perhaps it is a better fix to make it just a function that
returns void with early returns?

Thanks.

[gitgitgadget]

Junio C Hamano wrote on the Git mailing list (how to reply to this email):

Junio C Hamano <gitster@pobox.com> writes:

> From this function nothing returns an error anymore, and looking at
> the preimage of 663d7abe (http: reject unsupported proxy URL
> schemes, 2026-05-05) that is the source of the bug, the original did
> not do anything when the corresponding code did not find and set any
> proxy settings, either.
>
> So perhaps it is a better fix to make it just a function that
> returns void with early returns?

Nah, I was being stupid.  Disregard the above.

The whole point of 663d7abe was that we wanted to reject what we did
not recognise, and we cannot do so without returning "good/bad" from
that function.  The bug was that we did recognise https:// but still
returned -1 because of the bug, which the patch in the thread fixed.

Thanks.

[gitgitgadget]

Junio C Hamano wrote on the Git mailing list (how to reply to this email):

Junio C Hamano <gitster@pobox.com> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>
>> From this function nothing returns an error anymore, and looking at
>> the preimage of 663d7abe (http: reject unsupported proxy URL
>> schemes, 2026-05-05) that is the source of the bug, the original did
>> not do anything when the corresponding code did not find and set any
>> proxy settings, either.
>>
>> So perhaps it is a better fix to make it just a function that
>> returns void with early returns?
>
> Nah, I was being stupid.  Disregard the above.
>
> The whole point of 663d7abe was that we wanted to reject what we did
> not recognise, and we cannot do so without returning "good/bad" from
> that function.  The bug was that we did recognise https:// but still
> returned -1 because of the bug, which the patch in the thread fixed.

And as an important bugfix, this patch of course has been
fast-tracked.  I'll make sure we have it in 'master' before Git 2.55
gets tagged.

Thanks.