Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
curl returns correct LDAP result but after that hangs #622
I faced a strange issue while querying LDAP Active Directory via curl: directly and via R-language wrapper - RCurl.
When I run RCurl under R session on Windows, my query is evaluated and result is returned immediately. Everything is fine.
When I do the same under R on Linux Debian, it hangs. So I've run the query via curl from the Linux command line. It turned out that the result is returned correctly (all information is correct), but curl is waiting for something. Only Ctrl+C can stop that.
Why the query on Windows is evaluated successfully and curl returns results immediately, while the same query on Linux makes curl hanged? Should I set some additional options?
This may be important: Debian is running under Hyper-V virtual machine.
Thanks in advance.
I think you've hit the same problem discussed 10 days ago on the mailing list. Please look at thread http://curl.haxx.se/mail/lib-2016-01/0101.html.
There is no easy way to support automatic referrals chasing in curl yet.
Yes, you are absolutely right. I'm querying the Active Directory service. As for now I switched to the "ldapsearch" (from the openldap-tools package) tool and yes, it certainly displays "#refldap://". So yes, this may cause the problem. But, from the other side, why does it work on Windows? Exactly the same query is working smoothly under RCurl package on Windows.
Perhaps the source code of "lpdasearch" tool could help you to address this issue and handle the "referrals"?
Nevertheless, thank you very much for the quick and informative response!
I suppose the W$ curl version uses the ldap backend, not the openldap. I really do not know how referrals are processed in it, if at all.
On linux, if you use the workaround from my 1st reply, it should work.
The openldap backend chases referrals on secondary socket descriptors. Since curl is only able to monitor the primary socket descriptor for input availability, data from the secondary descriptors never trigger an "ldap_result()" call and thus, curl waits for the end-of-data record forever. This is the real problem.
I don't think so: ldapsearch has a single thing to do: satisfy your request, so it can handle requests synchronously. On the other hand, libcurl should be able to manage several easy handles at the same time (even if you have only one), so it uses asynchronous requests and select/poll calls to avoid suspension of program on socket reads.
Featuring the monitoring of several sockets for a single easy handle requires huge changes in the libcurl generic core, thus the correct fix for this issue will not be ready tomorrow :-/