Proxy support for non-winhttp connections

[alexcrichton]

I noticed today that the winhttp transport backend supports proxying HTTP requests, and I was curious if this was planned to be supported in libgit2 by default. If not, is it possible to get a handle to something like git_remote__get_http_proxy and implement a custom transport?

[carlosmn]

Exposing git_remote__get_http_proxy() shouldn't be an issue if it'd be useful externally.

The http-parser based transport should remain a fairly simple one. It should work in most situations, but there are better implementations out there. Maybe adding support for HTTP proxies is trivial and it would be worth supporting it, but for this kind of thing I was thinking of potentially having a serf or curl-based transport which would handle all the proxying or more complex authentication methods for us.

[alexcrichton]

That sounds like a good strategy to me! I think implementing a custom transport based on curl seems like a good idea, and I'll look into it.

[ghost]

Any progress on that? Would this transport be language agnostic?

I failed to use rugged (ruby-bindings for libgit2) behind a proxy.

[jessehouwing]

it would be nice if LibGit2 would use the default proxy resolve options for WinHttp if they are available and the standard git_remote__get_http_proxy did not return a proxy server. That would make it work like any default Windows application that is configured to use whatever IE is using.

[ethomson]

There's more discussion in #2589 - but as mentioned, it's not at all clear that we should be in the business of this (and certainly not by default, without the ability to override it). We match the git.git behavior now and even though I'm particularly sympathetic to the argument that they're doing it wrong, that doesn't mean that we should break compatibility, it means that we should agree on a common fix.

At the very least, I would like to see some tunable parameters in #2589 to make WPAD optional, because, ugh. (If you were going to tackle #2589, I would also note that the logic needs a lot of polish, but that's neither here nor there.)

[carlosmn]

Once #3183 and #3110 are fleshed out, it should be possible to set exactly what kind of proxy you'd like to use (assuming curl supports it).

[carlosmn]

If curl is installed on the system, we now use it by default, so we can support HTTP proxies both from the git configuration or curl will take it from the environment.

Run-time configuration isn't there yet, but it doesn't look like many programs actually would use that.

[carlosmn]

Fixed with #3110 which now lets the caller configure the proxy.