according to https://curl.se/libcurl/c/curl_easy_setopt.html, parameters
are either a long, a function pointer, an object pointer or a curl_off_t,
depending on what the option expects; curl 8.16 checks and warns about
these.
Include the -D flag for certificate verification in the "CHECK
CERTIFICATE" examples. Otherwise, only the certificate dates are
checked, but not if the certificate matches to the hostname or is signed
by a trusted CA.
Fixes#2146.
Check the UriUriA object, and if query string exists append it to the
new_url. Only appends the query part, fragments are still not appended
Function redir parses the new location header value using the
uriParseUriA function already, which populates the query field. This
field was already being printed, but it was not being appended to the
new_url during its construction.
Redirection chain of check_curl --onredirect=follow now mimics the chain
of check_http --onredirect=follow. Tested on the url:
mail.google.com/chat
* check_curl: avoid freeing memory when we don't know where it came from
* check_curl: when using -f sticky conserve IPv6 addresses properly
When running the check on an ipv6 address with a sticky onredirect
policy like in this example:
check_curl -6 -H example.com -I ::1 -f sticky
It results in a getaddrinfo error:
HTTP CRITICAL - Unable to lookup IP address for '[::1]': getaddrinfo returned -3 - Temporary failure in name resolution
This happens because in check_http() if the content of server_addr is an
ipv6 address enclosing brackets are added and on redirection a
subsequent call to check_http() will pass this now bracketed value to
getaddrinfo resulting in the error.
To work around this, strip the brackets from the address prior to the
lookup_host() call.
* add Michael Jeanson to thanks
This commit changes the behaviour of check_curl slightly.
Previously when the redirection method was set to the old 'check_http'
style redirection and there was no "location" header in the original
answer 'check_curl' segfaulted.
Now, at least it dies properly with a message.
This enables us to enable curl cookie engine by specifying an empty
filename as the cookie jar file.
This works, since curl's CURLOPT_COOKIEFILE option allows passing an
empty string as filename, which it interprets as a request to enable the
cookie processing. But since CURLOPT_COOKIEJAR would now attempt to
write to a file named by an empty filename, it would break again (or at
least produce a warning in verbose output).
Overall this is allows to handle checking URLs with cookie based
sessions without persisting the cookies to disk, by using the
curl-internal redirect following.
using check_curl on a probably embedded device responding as 'Server: GoAhead-Webs'
%> check_curl -H ... -S -vvv
> GET / HTTP/1.1
Host: ...
User-Agent: check_curl/v2.4.0 (monitoring-plugins 2.4.0, libcurl/7.76.1 OpenSSL/3.0.7 zlib/1.2.11 brotli/1.0.9 libidn2/2.3.0 libpsl/0.21.1 (+libidn2/2.3.0) libssh/0.10.4/openssl/zlib nghttp2/1.43.0)
Accept: */*
Connection: close
* Mark bundle as not supporting multiuse
* HTTP 1.0, assume close after body
< HTTP/1.0 302 Redirect
< Server: GoAhead-Webs
< Date: Tue Mar 26 17:57:16 2019
< Cache-Control: no-cache, no-store, must-revalidate,private
< Pragma: no-cache
< Expires: 0
< Content-Type: text/html
< X-Frame-Options: sameorigin
< X-XSS-Protection: 1; mode=block
< X-Content-Type-Options: nosniff
< Location: https://...
<
* OpenSSL SSL_read: error:0A000126:SSL routines::unexpected eof while reading, errno 0
* Closing connection 0
reading the discussion on https://github.com/openssl/openssl/discussions/22690 suggest to set the option SSL_OP_IGNORE_UNEXPECTED_EOF
which makes check_curl behave like check_http at this point.
Since this is a rather new flag, fencing it in ifdefs.
And since there can only be one ssl ctx function, we need to move both tasks into one function.
