> Have you tried the '--libcurl' parameter to take a peek at generated C code?
> Maybe there's the clue you're looking for.
>

Thanks! The three people I am working with on this (two of which have
used curl in projects for years) were completely unaware of this
extremely valuable feature. In my view, its existence should be stated
in bold font on page 1 of the library calls documentation, and not just be
listed only down at its current position in the long list of command line
flags for the free-standing utility.

For my issue, it turned out that one of the scenarios I had tried earlier
exactly matched the set of calls to curl_easy_setopt (but it didn't work).
However, the order of applying the settings was slightly different
than what --libcurl revealed. I didn't think that this mattered, but
apparently it does. When the various curl_easy_setopt() were done
in the order listed in the --libcurl output, it works. So while there
may be mystery about why the order of parameters mattered, as far as
taking care of the urgent task at hand, this issue is addressed, Thanks.

There are some follow-up questions.

1. When examining the output of curl --libcurl filename, some of the
curl_easy_setopt() settings don't seem to be related to command line
flags specified. Some may be just set to make the standalone program
behave reasonably, but I ended up chasing down a couple of these
mystery parameters like max redirects being set to 50, that sort of
thing. Is there documentation showing what --libcurl adds on its
own vs what was the result of command line flags?

2. When using libcurl on a FreeBSD 11 amd64 system using the curl-7.53.1 port,
I note that if you set errno=0 and then call curl_global_init(CURL_GLOBAL_ALL);
even that call returns 0, the process errno is now set to 22 (Invalid argument).
This doesn't seem to affect operation, but it may indicate something
is not working as expected within libcurl.

3. The documentation I have (with curl-7.53.1) regarding the need and
use of
     curl_global_init(CURL_GLOBAL_ALL); and
     curl_global_cleanup()
is somewhat contradictory or perhaps not up-to-date everywhere.
One place suggests curl_global_init() should only be called once
prior to use of the library by a given process. Another place says
that if you are using the curl_easy_init(), curl_global_init() isn't
needed. Yet-another place suggests that reality is that for each
use of curl should be preceded by both

     curl_global_init(CURL_GLOBAL_ALL) and
     curl_easy_init()

then after curl_easy_setops and curl_easy_perform

     curl_easy_cleanup(); and
     curl_global_cleanup();

then repeat the entire set of calls should you want to do another
curl_easy_setopt/curl_easy_perform sequence.

The examples on the web site don't really cover this situation I am
trying to address, as each sample program tends to do one query and
exit. They don't continue running and potentially do additional
queries using the curl library.

So, what is reality? I find doing the above sequence works and
doesn't appear to cause harm or leak memory, but I'd rather not be
doing stuff that doesn't make sense or could cause problem after
repeated curl_easy_perform operations.

Thanks for the wisdom,

- Frank

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2017-09-15