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.
Variables only used in that specific translation unit should be static
to actually communicate that fact.
Also allows the compiler to detect unused (global) variables.
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>
