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.
Previously the --state-regex option accepted only "critical" and
"warning" as values.
This commit changes the strcmp there to strcasecmp to be more tolerant
regarding the input.
The help output of `check-curl` contained a typo,
the real option is `state-regex` and not `regex-state` as
the help suggests.
Also added the two possible options to avoid confusion.
From the mere help output for -C / --certificate, I was confused about
what its two integer parameters do. Unfortunately, I also missed out on
the explaining examples later. Since I like to have basic documentation
for each flag, I tried to make the arguments as short as possible.
The other fix was one hyphen too many for the --cookie-jar option.
Having a webserver respond with a relative redirect as for ex. in `Location: /path/to.html`
check_curl would use the wrong standard http/https port instead
of crafting the absolute url using the given scheme/hostname and port.
Adding a new test case for this for check_http and check_curl. check_http did
it correct already, so no fix necessary there.
before:
%>./check_curl -H 127.0.0.1 -p 50493 -f follow -u /redirect_rel -s redirected -vvv
**** HEADER ****
HTTP/1.1 302 Found
...
Location: /redirect2
...
* Seen redirect location /redirect2
** scheme: (null)
** host: (null)
** port: (null)
** path: /redirect2
Redirection to http://127.0.0.1:80/redirect2
fixed:
%>./check_curl -H 127.0.0.1 -p 50493 -f follow -u /redirect_rel -s redirected -vvv
**** HEADER ****
HTTP/1.1 302 Found
...
Location: /redirect2
...
* Seen redirect location /redirect2
** scheme: (null)
** host: (null)
** port: (null)
** path: /redirect2
Redirection to http://127.0.0.1:50493/redirect2
Signed-off-by: Sven Nierlein <sven@nierlein.de>
* lib/utils_base.c
* plugins/check_curl.c
* plugins-root/check_dhcp.c
Removed a line which theoretically can not do anything, but there was
comment which indicated something else. Still trying this though.
check_curl fails on large pages:
HTTP CRITICAL - Invalid HTTP response received from host on port 5080: cURL returned 23 - Failure writing output to destination
for example trying to run check_curl on the test from #1822
I guess the idea is to double the buffer size each time it is to small. But the code
exponentially grows the buffer size which works well 2-3 times, but then fails.
* If server_address is an IPv6 address surround it with brackets
* If the message is too short, we should not have an underflow
* Add simple conditional test case available if IPv6 is
