check_http expects >0 response headers

[nagios-plugins]

check_http expects >0 response headers

[jfrickson]

Fixed in the main branch via commit 224b1e5

[sreinhardt]

I don't believe this is a bug, although I would agree it could be documented better.

-s is for checking strings within the content section
-d is for checking strings within the headers
-e is for checking from status down.

I wrote a really simple app to receive the http request and returns "HTTP/1.0 200 ok\n\r\n\rOK!!! $date\0". Using -s does fail to match the string as there is no content section, -d does work properly for checking OK but not ok, as expected. Please let me know if you see anything different, but I believe that is all the changes you should need.

[PriceChild]

I'm not sure I follow your response. In your test return, shouldn't \n\r\n\r be \r\n\r\n ?

Please could you post the output of check_http when using -s together with -v? I would be very interested to see whether the 'OK!!! $date\0" is reported in the "**** HEADER *_" or "_* CONTENT ****" section. This is the behaviour I'm querying. I have no reason to believe that -s, -d or -e work incorrectly but I do suspect that check_http is incorrectly parsing the http response when deciding which bit is the status line, headers & content sections.

An easy way to reproduce, in one terminal:

nc -l 12345

and in the second:

check_http -H localhost -p 12345 -v

then in the first, paste:

HTTP/1.0 200 OK

OK!!!

(with a few hits of the return key that i can't manage to show in markdown) before control+c'ing.

In the second, I see:

GET / HTTP/1.1
User-Agent: check_http/v1.4.16 (nagios-plugins 1.4.16)
Connection: close
Host: localhost:12345

http://localhost:12345/ is 24 characters
STATUS: HTTP/1.0 200 OK
**** HEADER ****
OK!!!
**** CONTENT ****

HTTP OK: HTTP/1.0 200 OK - 24 bytes in 3.933 second response time |time=3.932539s;;;0.000000 size=24B;;;0

and I think that the 'OK!!!' in the HEADER section should actually be in the CONTENT section?

Or am I producing an invalid http response?