On 9/14/2017 11:11 PM, Frank Durda IV wrote:
> 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?

No. --libcurl shows you the options set by the tool even if they are not
the options that you set yourself.

> 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.

That's nothing to worry about. Generally speaking errno is only relevant
when it is documented that it will be set, otherwise consider it an
arbitrary value. libcurl returns errors via CURLcodes [1], however you
can retrieve the errno of a connect failure by using CURLINFO_OS_ERRNO [2].

> 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.

Please give citations so we can correct any mistakes. Basically call
curl_global_init once at the beginning of your program and
curl_global_cleanup once at the end. Neither is thread-safe. Please
refer to the doc at [3].

libcurl has a so-called "lazy initialization" that takes place if
curl_easy_init is called and the library is not initialized. Do not rely
on that, it's of limited use and can cause problems if it occurs when
other threads are running.

Also- I see in the post that started this thread that you are using
option -k which disables certificate verification by setting
CURLOPT_SSL_VERIFYPEER and CURLOPT_SSL_VERIFYHOST to 0. I would remove
those two lines from your --libcurl output so it will use the defaults
instead. If there is a certificate problem you should address that
rather than disable the verification.

[1]: https://curl.haxx.se/libcurl/c/libcurl-errors.html
[2]: https://curl.haxx.se/libcurl/c/CURLINFO_OS_ERRNO.html
[3]: https://curl.haxx.se/libcurl/c/curl_global_init.html

.

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