On Mon, 29 Sep 2008, Dan Fandrich wrote:

> I noticed that the error code returned when the synchronous host resolver
> times out is the same as when it can't be resolved at all:
> CURLE_COULDNT_RESOLVE_HOST. But when the timeout proposed to be set is
> shorter than a second (so a timeout can't be set) or if a previously-set
> alarm couldn't fire because the resolver was busy, the error returned is
> CURLE_OPERATION_TIMEDOUT. The latter code is also what's returned when a
> connect can't complete due to reasons other than the host resolver.
>
> Was this distinction being made deliberatly?

I think the reasoning behind this was that if the name resolving was even
started, a time-out in the middle caused CURLE_COULDNT_RESOLVE_HOST but if the
time-out occurred before the resolve was even attempted it would make a
CURLE_OPERATION_TIMEDOUT.

> I would have expected a resolver timeout to return CURLE_OPERATION_TIMEDOUT
> in each case above.

I don't have any strong opinions about this, but a timed-out resolve is a
failed resolve too and I would think that even function calls for name
resolving have internal time-outs etc so a "normal" failed resolve can indeed
be due to a time out as well....

-- 
  / daniel.haxx.se