On Tue, October 6, 2015 6:46 am, Axel Beckert wrote:
Hi,
one our HTTP checks went yellow today because the Apache being tested responded with a "304 Not Modified" HTTP code, and the check went yellow.
"304 Not Modified" is generally a valid HTTP answer which does not indicate a problem but rather a properly working server -- if the client provided the according meta information, namely either the If-Modified-Since or If-None-Match HTTP headers.
But xymonnet doesn't seem to send either of them, at least according to a quick grep through the xymon's source code.
So I think that if xymonnet receives a 304 reply, there must be something wrong on the server side (broken reverse proxy or similar), hence the yellow state is some kind of justified.
What do others think about that topic?
Kind regards, Axel Beckert
I'd consider it a valid use case for a yellow, since by construction there's really no expectation that xymonnet would actually receive that, as you said. (As opposed to a 301/2/3, which could be entirely reasonably for a retrieval.)
On a related note, I'd been holding off on committing Mark's patch from https://sourceforge.net/p/xymon/mailman/message/34420580/ until I had a chance to go through the "extended" HTTP RFCs and make some sort of red/yellow determination. If the community had an agreement on suitable defaults, that would help.
Ultimately, making a default mapping of HTTP codes to each state via config variable would make the most sense (sort of uplifting the 'httpstatus:' logic), since there'll be variation desired from site to site. Performance impact does have to be considered for larger sites and xymonnet runs, however.
-jc