Bugs item #3579151, was opened at 2012-10-22 08:40
Message generated for change (Comment added) made by bagder
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=3579151&group_id=976

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: name resolving/DNS
Group: None
>Status: Pending
>Resolution: Invalid
Priority: 1
Private: No
Submitted By: Philippe Demange (phdems)
Assigned to: Daniel Stenberg (bagder)
Summary: Better return COULDNT_RESOLVE_HOST iso TIMEDOUT ?

Initial Comment:
Hi,

running on Debian stable, and testing resolution errors, I got a CURLE_OPERATION_TIMEDOUT if I use the opt CURLOPT_TIMEOUT, but the error CURLE_COULDNT_RESOLVE_HOST if I don't use it, after 63 seconds.
Wouldn't it be better to return CURLE_COULDNT_RESOLVE_HOST in both cases, firstly to keep coherency between these two similar use cases, and secondly to allow a more precise diagnostic ?

Attached is a patch for that puspose.

Many thanks in advance.
Regards.

----------------------------------------------------------------------

>Comment By: Daniel Stenberg (bagder)
Date: 2012-11-11 23:54

Message:
If you want to ask questions on how libcurl acts and works in different
situations, then please use the curl-library mailing list. I cannot see a
reason to change the current behavior and if you want to argue FOR that,
you need to do that on the mailing list as well to see what others think.

This is not a bug.

----------------------------------------------------------------------

Comment By: Philippe Demange (phdems)
Date: 2012-10-30 06:12

Message:
Thanks for reporting this issue and helping us improve curl and libcurl.

We're awaiting feedback in this issue. Due to this, I have set the state of
this issue to pending and it will automatically get closed later on unless
we get further info.

Please consider answering the outstanding questions or providing the
missing info so that we can proceed to resolve this issue!

----------------------------------------------------------------------

Comment By: Philippe Demange (phdems)
Date: 2012-10-30 05:39

Message:
Thanks Daniel for your answer.

What leaded me to propose this patch is that when I set the option
CURLOPT_TIMEOUT, I can see the trace "Resolving timed out after %ld
milliseconds", which seems to me very clear about what really happened
(it's a resolution timeout, not a connection timeout), whereas the error
code CURLE_OPERATION_TIMEDOUT looks like having lost the information of the
root cause of the timeout.

Now, maybe am I mis-interpreting this trace, or it's giving a wrong view of
the root cause? In such case, maybe a minor modification of this trace
would avoid the confusion I experienced ...

Anyway, your answer makes me think that I am maybe not using correctly the
API. To be more precise, I just want to test if a hostname is correctly
resolved, by taking benefit of the c-ares through the libcurl's API; so my
first approach has been to:
- set the option CURLOPT_CONNECT_ONLY
- set the options CURLOPT_CONNECTTIMEOUT and CURLOPT_TIMEOUT
- and then just perform the request
which is to me an easy and quick way to do what I want.
Finally I removed the option CURLOPT_CONNECTTIMEOUT, thinking it could
resolve my problem, in the sense that now, the CURLE_OPERATION_TIMEDOUT
error can only happen because of a DNS timeout and not because of a
connection timeout; but this is just a guess and needs confirmation.

Also, I am wondering if I should purely use directly c-ares API directly
(but this, for sure, has the inconvenient to require some deep
modifications of my code, which is strongly based on libcurl's API); would
you suggest me to do so anyway, or my first approach would finally give the
same result ?

Once again, many thanks for your time and support.

Philippe.

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2012-10-29 14:49

Message:
While I appreciate your line of thinking, I've been faced with the complete
opposite in the past and we have since then landed with this approach. Now
you at least know that your timeout caused the error, as if it had returned
a resolve error you couldn't have known if it was truly not resolving or a
result of your timeout.

I don't plan to modify this return code, sorry.

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=3579151&group_id=976
Received on 2012-11-12