2.3.2 breaks -s, -r, and -R for check_http

[leres]

After upgrading to nagios-plugins 2.3.2 I'm unable to get any of the -s, -r, or -R flags to work with check_http:

Code: Select all

  # 2.3.1 works
fun 235 % pkg info nagios-plugins | fgrep Version
Version        : 2.3.1,1
fun 236 % /usr/local/libexec/nagios/check_http -S -H www.freebsd.org -s operating
HTTP OK: HTTP/1.1 200 OK - 26414 bytes in 0.393 second response time |time=0.393414s;;;0.000000 size=26414B;;;0

Code: Select all

 # 2.3.2 fails
dot 241 % pkg info nagios-plugins | fgrep Version
Version        : 2.3.2,1
dot 242 % /usr/local/libexec/nagios/check_http -S -H www.freebsd.org -s operating
HTTP CRITICAL: HTTP/1.1 200 OK - string 'operating' not found on 'https://www.freebsd.org:443/' - 8195 bytes in 0.351 second response time |time=0.350931s;;;0.000000 size=8195B;;;0

Reverting the recent change to document_headers_done() solves this, I did not attempt to debug further.

[leres]

Actually I did debug a bit more: adding -v to my http://www.freebsd.org examples shows that 2.3.1 gets 583 lines of content/body while 2.3.2 only gets 177 lines.

[swolf]

Hi @leres,

Thanks for reporting this. I was able to reproduce the issue, looking into it.

EDIT: I think I have the issue resolved, see here for the patch.

[leres]

Thanks for the patch! I can confirm it solves this. I created this FreeBSD PR.

[leres]

Ooosp! While your patch does fix check_http when the http server provides a content-length header is does not help if the header is missing.

By my read of the spec, content-length is not required:

https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

Applications SHOULD use this field to indicate the transfer-length of the message-body ...

And indeed I see servers (especially embedded devices) do not always provide it. The 2.3.2 changes to check_http make it impossible to use these flags with these servers.

[swolf]

Thanks for pointing that out - the same branch should now handle that case. I also went through and tested the other methods listed in section 4.4 of the RFC and I think the updated plugin is consistent with that section.