On Tue, 22 Mar 2005, samg samg wrote:

> It's the problem, my proxy is not www.python.org
> I modified the program like that :
> c.setopt(pycurl.PROXY, "proxy:8080")
> c.setopt(pycurl.URL,
> 'http://www.python.org/pics/PyBanner049.gif')
>
> the SAME code works with the No-SSL version, but fails with the SSL version.

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.

> 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?

> 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 am one of the main developers of c-ares too, and I work hard on making it do
right all over. I'm very interested in getting to know about bugs in c-ares so
that we can fix them.

> I have doubts on libidn and c-ares.

... and why would you have doubts on libidn?

-- 
      Daniel Stenberg -- http://curl.haxx.se -- http://daniel.haxx.se
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html
_______________________________________________
http://cool.haxx.se/mailman/listinfo/curl-and-python