This comment has been minimized.

edited

Member

I think you need to allow this function to return at least an error for whatever went wrong in the callback that makes the code want to stop the transfer. So maybe just an int and let 0 mean OK, 1 means "error, stop, get out" and the rest left reserved for the future?

This comment has been minimized.

Sure, thanks for the suggestion - I've fixed the failing TCs and added the example, will add the two other issues you mention (recursive CB attempt + return code) on a subsequent commit. Thanks for the help.

This comment has been minimized.

edited

I'm really sorry, but I rather err on the safe side rather than hurry to get something in before the curtain falls. I have not had time yet to check this out closer and properly consider the API and function arguments etc - and nobody else has stepped up with feedback (neither positive nor negative). I need more time, so it will not get merged in this feature window. I apologize for this, but I've had a few very busy weeks at work lately and it has made me have less time to curl.

- Add new option CURLOPT_RESOLVER_START_FUNCTION to set a callback that
will back called before resolver start (ie before a host is resolved)
with a pointer to backend-specific resolver data.
- Add new option CURLOPT_RESOLVER_START_DATA to set a user pointer to
pass to the resolver start callback.
Closescurl#2311

- Add new option CURLOPT_RESOLVER_START_FUNCTION to set a callback that
will back called before resolver start (ie before a host is resolved)
with a pointer to backend-specific resolver data.
- Add new option CURLOPT_RESOLVER_START_DATA to set a user pointer to
pass to the resolver start callback.
Closescurl#2311

- Add new option CURLOPT_RESOLVER_START_FUNCTION to set a callback that
will back called before resolver start (ie before a host is resolved)
with a pointer to backend-specific resolver data.
- Add new option CURLOPT_RESOLVER_START_DATA to set a user pointer to
pass to the resolver start callback.
Closescurl#2311

- Add new option CURLOPT_RESOLVER_START_FUNCTION to set a callback that
will be called every time before a new resolve request is started
(ie before a host is resolved) with a pointer to backend-specific
resolver data. Currently this is only useful for ares.
- Add new option CURLOPT_RESOLVER_START_DATA to set a user pointer to
pass to the resolver start callback.
Closescurl#2311

This comment has been minimized.

I moved the callback into Curl_resolv right before Curl_getaddrinfo is called. This way it is called for all backends, even though currently it appears only to have a benefit for the ares backend. I also added a 'reserved' pointer to the callback in case we want to expand on it in the future. (For example allowing the user to receive the hostname/port and do their own resolve maybe?)

The EXAMPLE in the doc I don't think is sufficient since it just shows resolver_state pointer address. It could really use an example that shows how the resolver_state should be used with ares, like if multiple hostnames are resolved do you set the socket multiple times? etc, or how in practice it is used.

Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.