For example site.com resolves to 1.2.3.4. The owner of site.com change DNS and site.com resolves to 4.3.2.1. We try to connect site.com and can't do it but don't understand why. If in CURLINFO_PRIMARY_IP was IP of site.com we could see that curl used cached from DNS old IP 1.2.3.4 (not new 4.3.2.1).

And it works in curl 7.21.0 on Debian 6. But in new versions of curl we receive just empty string from CURLINFO_PRIMARY_IP and don't know which IP curl try to use.

I think much better will be to return IP if only resolving was successful.

02.05.2017, 15:11, "Daniel Stenberg" <daniel_at_haxx.se>:
> On Tue, 2 May 2017, D M via curl-library wrote:
>
>>  If request wasn't successful CURLINFO_PRIMARY_IP is empty in new versions of
>>  curl (in versions of curl several years ago it wasn't empty).
>
>>  Why new versions of curl have empty value in CURLINFO_PRIMARY_IP if request
>>  wasn't successful?
>
> Because it stores that info only after a successful connect. I think because
> it also extracts and stores information about port numbers from the connection
> and they are of course absent if the connection failed.
>
> In general we focus on making sure we return proper info for successful
> transfers.
>
>>  Is it a bug?
>
> I don't think it is. The exact wording in the documentation for
> CURLINFO_PRIMARY_IP is:
>
>    receive the pointer to a zero-terminated string holding the IP address of
>    the most recent connection done with this curl handle
>
> So if there was no connection made, there's not necessarily any information
> given - but it would also be complicated to document when it provides the
> information if it also would do it for *some* errors.
>
> I wouldn't be totally against allowing it to return the information for this
> sort of timeouts.
>
> --
>
>   / daniel.haxx.se
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2017-05-02