check_http timeout due to non-close with chunked encoding

[Daniel Beardsmore]

Since this is check_http v2.1.1 from Debian 8, and may now be resolved, but I'll report this anyway just in case it's enough of an edge case to have not yet been detected and reported.





We have a server application (F-Secure Policy Manager Server for Linux) that in its latest version (13) uses chunked transfer encoding and does not close the connection after sending the final chunk. (Testing the non-secure port with telnet shows that it sits and waits for the client to close the connection.)



check_http requires the server to close the connection after the final chunk is set, and when the HTTP(S) server does not close the connection, check_https times out the connection.



The bigger problem is that verbose mode (-v) pretends that no data was received. It does not write output in real time, and it doesn't report even the headers unless the connection was successful. What -v should show, is everything received up to the point that the connection timed out. Instead, it makes it look like the connection is being blocked somewhere and that nothing was received, not even the headers.



For HTTP, I can use telnet to probe the output directly (testing in links from the Nagios server showed that it was not a firewall problem -- I could see that it was Nagios-specific somehow). For HTTPS, I cannot do that. Fortunately, this server has both HTTP and HTTPS modes, making testing easy. If it was HTTPS-only, I'd have to use something like openssl client to run the tests, something that is possibly less well-known.





Granted, it's a real edge case, but I thought I'd mention it anyway in case anything can be done to help other admins with similar situations (either servers that leave the connection open, or situations where connections hang half-way through, which I've seen before due to networking problems.)





Regards



Daniel.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-plugins.org/archive/devel/attachments/20180216/13a91255/attachment.html>