Closed adamkerz closed 9 years ago
I see the same slow behaviour, same software setup.
Git uses cURL internally to perform (almost) all HTTP communication. You could try to run
curl -x http://localhost:8080 <url>
to see whether cURL without Git shows the same behavior, and then continue investigating from there.
Using git's own curl binary, I see a connection to the proxy within a second and the response dumped to stdout straight after. Would a more complicated curl command be being used that could influence this or is it more likely to be whatever git's doing beforehand?
Would a more complicated curl command be being used
No, Git uses cURL as a library. Well, I guess that was what you're driving at: Git does not use that executable.
There are some facilities included in Git that should help debugging this: setting the environment variables GIT_TRACE=1
and GIT_CURL_VERBOSE=1
.
BAM! IPv6: I'm not listening on ::1
, only 127.0.0.1
* About to connect() to proxy localhost port 38080 (#1)
* Trying ::1...
* Connection refused
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 38080 (#1)
* Establish HTTP proxy tunnel to github.com:443
Between * Trying ::1...
and * Connection refused
is the delay.
Interestingly, I was initially telling Cntlm to listen on 38080
only:
section: global, Listen = '38080'
cntlm: Proxy listening on 127.0.0.1:38080
and then I tried:
section: global, Listen = 'localhost:38080'
Resolve localhost:
-> 127.0.0.1
cntlm: Proxy listening on 127.0.0.1:38080
But both times it only bound to 127.0.0.1
. Not sure what the expected behaviour is, more an inconsistency between cURL and Cntlm (and between the cURL library and the curl binary).
I think you probably DO want to try IPv6 first if the os supports it, so I doubt there's much more to do. It's documented and hopefully others with the same problem can find this page easily enough.
@dscho, thanks for the hints on getting more info to debug the problem! Should this be closed or do you have a different opinion to me about resolving this issue?
Good catch! The only thing to be done before closing this ticket might be to enhance the FAQ. How about giving it a try?
Do we really wait 2.5 minutes to realize the connection is refused? That sounds like a problem, IMO.
@kusma well, if a connection is refused, cURL does not wait to let the user know. So my guess is that the firewall tries to fend off port scanning (and thereby causes the delays). But you're correct, this is just a guess on my part.
In any case, I think it would make sense to describe in the FAQ how to debug such situations.
Done (towards the bottom of the FAQ page), any feedback is welcome and then close the issue :-)
When I set my
.gitconfig
to contain:And then run
git clone "http://github.com/blah" blah
Takes exactly 2.5 minutes without ever connecting to the proxy server before presumably timing out and then connects to the proxy server and completes quickly.
Changing to:
The 2.5 minute delay disappears and git connects to the proxy straight away.
nslookup localhost
resolves to127.0.0.1
quicker than I can blink.Also described here: http://stackoverflow.com/questions/5060437/configuring-git-on-windows-to-use-ntlm-proxy-authentication/23349704#23349704
Using Windows 7, git version 1.9.5.msysgit.0 and CNTLM.