Re: [PATCH] http: do not ignore proxy path
- From
Ryan Hendrickson <ryan.hendrickson@alum.mit.edu>
- Date
- Jul 26, 2024, 22:43 UTC
- Message-ID
- <4f962eaa-d12b-d250-dd93-a1673af850c6@alum.mit.edu>
- In-Reply-To
- <20240726211156.GA714986@coredump.intra.peff.net>
At 2024-07-26 17:11-0400, Jeff King <peff@peff.net> sent:
> I would warn that there are several not-quite-compatible variants of > netcat floating around, which can create headaches. You might be better > off with a short perl script using IO::Socket::UNIX or similar.
Ah, okay, thanks for the pointer!
Show 24 quoted lines
>> diff --git a/http.c b/http.c
>> index 623ed234891..0cd75986a6b 100644
>> --- a/http.c
>> +++ b/http.c
>> @@ -1265,7 +1265,13 @@ static CURL *get_curl_handle(void)
>> if (!proxy_auth.host)
>> die("Invalid proxy URL '%s'", curl_http_proxy);
>>
>> - curl_easy_setopt(result, CURLOPT_PROXY, proxy_auth.host);
>> + if (proxy_auth.path) {
>> + struct strbuf proxy = STRBUF_INIT;
>> + strbuf_addf(&proxy, "%s/%s", proxy_auth.host, proxy_auth.path);
>> + curl_easy_setopt(result, CURLOPT_PROXY, proxy.buf);
>> + strbuf_release(&proxy);
>> + } else
>> + curl_easy_setopt(result, CURLOPT_PROXY, proxy_auth.host);
>
> The fields in the proxy_auth struct have been parsed from the url, with
> any url encoding removed. But then we paste them back together into a
> pseudo-url without doing any further encoding. Is that correct?
>
> I doubt that the host contains a "/", but if you had a path that
> contained a "%", then the URL form of that is going to be %25. Which is
> curl expecting to get here?Oh, I see! Yes, this is an issue with my patch: if I create a socket file named "%30", command-line curl wants http_proxy to contain "%2530", and patched Git wants http_proxy to contain "%252530". Good edge case to put in a test.
> I wonder if we could go back to passing the string straight to curl (as > we did prior to 2016), and keeping the proxy_auth struct purely as a > mechanism for gathering credentials.
Hmm, that would be nice, but I think curl doesn't deal well with the extra case that Git supports of specifying a username but no password. It causes one of the existing tests to fail if I pass the string straight through.
On top of that, all of those starts_with tests for checking the protocol are written quite loosely, so in practice Git "supports" the protocols "socks://" and "socksonmyfeet://" by mapping them both to SOCKS4, and curl would not like it if it received those strings directly.
So given that Git wants to handle the protocol and the credentials, it makes sense that only the host and the path are passed to curl. I just have to make sure that they are correctly re-encoded.
R