Intermittent failure in libcurl when git cloning through authenticated HTTP proxy #2088
Comments
If my fix looks reasonable, I can open a PR for it. |
Sorry for responding slowly. The suggested change is unfortunately not good enough. That function call will block waiting for activity until it times out if there is none, and that's a non-blocking function (like most libcurl internals are or should be). When |
@bagder I figured that may be the case. I just took another look at it, and because |
… CONNECT (Resolves curl#2088)
I did this
Using an authenticated HTTP proxy, running
git clone https://[git path]
results in intermittent failures due to "Proxy CONNECT abort".After a bunch of debugging (with
GIT_CURL_VERBOSE=1
), I traced the issue to libcurl. The following differences were observed in the output:Working:
Failing:
Notice that in the failing case, there is no "Connect me again please" log and it does not create a new connection to the proxy (since the proxy previously said to close the connection).
Running
git bisect
to find the first commit where this was issue was first experienced, I traced it to commit 5113ad0Further debugging led me to 5113ad0#diff-a609379a03db55c0a6fe3865f3b5cb46R347,
where one of the
if
blocks was removed. If I put theif
block back (code diff against latest master (commit 6ce9845) below), I no longer get intermittent failures whengit clone
ing (It appears that state about closing the connection is lost when returning into the function at a later time). However, I'm not familiar with the curl codebase to know if there are other side effects from re-introducing thisif
block.I expected the following
No intermittent failures when
git clone
ing.curl/libcurl version
On Alpine 3.4:
[curl -V output]
On Debian Buster:
[curl -V output]
The text was updated successfully, but these errors were encountered: