New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CURLINFO_PRIMARY_IP empty if connection fails #2126

Closed
rcanavan opened this Issue Nov 29, 2017 · 4 comments

Comments

Projects
None yet
2 participants
@rcanavan

rcanavan commented Nov 29, 2017

CURLINFO_PRIMARY_IP is empty if a connection attempt fails, e.g. due to a timeout. However, the IP would be useful to diagnose connection problems, especially in case a server name resolves to multiple IPs. As a workaround, one can search for "Trying ..." in the debug output, which should always be present if connection problems arise.

If this is the intended behavior, please clarify the documentation at https://curl.haxx.se/libcurl/c/CURLINFO_PRIMARY_IP.html to read "get IP address of the last successful connection"

reproduce with following trivial hack of examples/getinfo.c

#include <stdio.h>
#include <curl/curl.h>

int main(void)
{
  CURL *curl;
  CURLcode res;
  char *ct;

  curl = curl_easy_init();
  if(curl) {
    curl_easy_setopt(curl, CURLOPT_URL, "http://blackhole.webpagetest.org/");
    curl_easy_setopt(curl, CURLOPT_TIMEOUT, 3);
    res = curl_easy_perform(curl);

    if(CURLE_OK == res) {
      /* ask for the content-type */
      res = curl_easy_getinfo(curl, CURLINFO_CONTENT_TYPE, &ct);

      if((CURLE_OK == res) && ct)
        printf("We received Content-Type: %s\n", ct);

    }
    res = curl_easy_getinfo(curl, CURLINFO_PRIMARY_IP, &ct);

    if((CURLE_OK == res) && ct)
      printf("IP: %s\n", ct);

    /* always cleanup */
    curl_easy_cleanup(curl);
  }
  return 0;
}
@bagder

This comment has been minimized.

Member

bagder commented Nov 30, 2017

Well, if it can't connect it is by definition never a connection so the documentation is actually already saying this.

the IP would be useful to diagnose connection problems, especially in case a server name resolves to multiple IPs

But if there's more than one IP returned, there isn't one IP to return in the case of failure so it would still be problematic to use this variable for that purpose.

@rcanavan

This comment has been minimized.

rcanavan commented Nov 30, 2017

Well, if it can't connect it is by definition never a connection so the documentation is actually already saying this.

I'm not quite convinced, but then again, I'm not a native speaker - I think the current wording is somewhat ambiguous, although clearly consistent with the current behavior.

But if there's more than one IP returned, there isn't one IP to return in the case of failure so it would still be problematic to use this variable for that purpose.

But only one specific IP is used to attempt to open a TCP connection. If that times out, I'd like to know which one was actually used. Especially if CURLOPT_RESOLVE or CURLOPT_CONNECT_TO may have been used, possibly in conjunction with Connection reuse.

To make things clear, I consider this "issue" to be more on the side feature request as opposed to a bug report.

@bagder

This comment has been minimized.

Member

bagder commented Nov 30, 2017

I think the current wording is somewhat ambiguous,

We could indeed improve the phrasing to make the meaning clearer and more obvious.

But only one specific IP is used to attempt to open a TCP connection

No. libcurl tries two addresses at a time when doing happy eyeballs and it also goes over subsequent addresses if one fails to connect so it can indeed have tested tens of addresses when it fails. Reporting the last tested IP as failed would be misleading. If it should have a feature to report failed addresses, it should be able to report a list of them, I think.

But then, since the addresses can come from a few different places, won't you pretty much need the verbose output anyway to make something out of the addresses? Does it really help to offer the application a set of addresses that were tested?

@rcanavan

This comment has been minimized.

rcanavan commented Nov 30, 2017

No. libcurl tries two addresses at a time when doing happy eyeballs and it also goes over subsequent addresses if one fails to connect so it can indeed have tested tens of addresses when it fails. Reporting the last tested IP as failed would be misleading. If it should have a feature to report failed addresses, it should be able to report a list of them, I think.

Thanks, I wasn't aware of this. That means we'll have to alter our current workaround (looking for " Trying ..." in the debug text.

Does it really help to offer the application a set of addresses that were tested?

We'd like to log the failed addresses, so that we stand a chance to diagnose the problem later. If multiple addresses were used, an error message or error code for each address may be helpful as well.

@bagder bagder closed this in 3b9ea70 Dec 11, 2017

@lock lock bot locked as resolved and limited conversation to collaborators May 6, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.