Daniel Stenberg wrote:
> But this problem can't be the fault of c-ares. libcurl is responsible
> for deciding what host name to resolve and when you use a proxy it
> should only resolve the proxy host name. This decision is identical
> and made the same way no matter what resolver-backend libcurl is built
> to use.
> This rather looks like the proxy setting isn't set in the libcurl
> handle and thus it tries to resolve the remote server name.
It's possible .... i don't know the internals of libcurl. What
astonishes me, it's that it works on the basic version of libcurl.
But the version with OpenSSL,zlib/1.2.2,c-ares,libidn fails. Thus, for
me, the problem must come from one on these libraries, and c-ares and
libidn are good candidates for that (IMHO).
Perhaps that the fact to link with c-ares has an undesirable effect on
>> Furthermore, even when the host is in my intranet, the resolve fails
>> (while ping on hostname works)
> So the c-ares version NEVER works then?
With the SSL-version of pycurl and when i use a proxy, that always fails
whether the site is on Intranet or Internet.
>> Because, i have already had a problem with this library, so it lost
>> my trust
> I don't see how that thread identified bugs in c-ares. Please point
> out where I'm wrong.
I cannot say much more, i did not have the time to debug, but it's a
fact... In Windows 98 (only 98 and on 2 PC), when pycurl is linked with
c-ares and the url is https, it's impossible to initialize a curl
object. I have compiled two versions of pycurl (zlib+openssl and
zlib+openssl+c-ares), the version with c-ares has always failed. (no
problem without c-ares)
> ... and why would you have doubts on libidn?
As i mentioned above, it's just because without these libraries, all is
It's just my conclusion ^_^ , but you know your subject surely better
I hope that you don't have too much trouble to understand me in spite of
my poor English
Received on 2005-03-22