Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Race Condition in Curl_proxyCONNECT (bug # 39) #1132
libcurl v 7.51
A FTPs transfer using a HTTP proxy sometime timeout with the following messages:
The bug # 39 is not in the list of known issue anymore. Commit b207ccb remove it.
There is no known bugs numbered like that anymore so if you want something added to
But then I also don't really see the big value of having this mentioned there. Isn't it instead much better to work on actually fixing the issue you have? Can you provide an example that repeats the problem and possible show us
Sadly, it's a race condition. In some cases, libcurl will read the FTP welcome message as being the HTTP proxy response body and thus will never receive the FTP welcome. That means that it is almost impossible to reproduce predicatively with a real HTTP proxy.
So, I've made a (partial) fake HTTP proxy server (curl39.txt). This (C++) program simply accept one connection and send back in a single write:
With this server and curl command lineline:
As we can see, CURL never did see the welcome message from the FTP server (because it is the 32 bytes of opaque data).
I've tested the fix of https://curl.haxx.se/mail/lib-2015-04/0169.html and it does resolve the problem.
Sadly, it also break three tests (206, 1060 and 1061). All of those tests have HTTP proxy that return data in the proxy response. From the discussion on the mailing list, it appear that behaviour is broken for a HTTP proxy.
What should be the next step? Should I open a pull request and move the discussion there or would it be better to discuss impact/alternatives in this issue first?
Please do submit a PR. Regarding the test failures, it'd be great if you fixed them as well while at it. The spec text to lean on comes from RFC7231 section 4.3.6:
Here's my suggested patch for this problem: 0001-CONNECT-fix-race-condition.patch
It now returns error on
It actually also made me find and fix a bug that probably can happen with the old code if that would end up reading the response one byte at a time too (a rare scenario).
This patch is a squashed version of three separate commits that I want to merge, but serves as easier to test. I've also updated a bunch of test cases that were broken (used wrong or no headers), and some that actually sent the unaligned data amounts - where