Xymon Mailing List Archive search

http test -- 202 status red after upgrade from 4.3.21 to 4.3.23

6 messages in this thread

list Shawn Heisey · Mon, 23 Nov 2015 11:05:19 -0700 ·
I have an http test that returns a 202 response, which was perfectly
acceptable when the xymon server was running 4.3.21.  Today I upgraded
it to 4.3.23, and now that 202 response is generating a red alarm.

Here's a relevant excerpt from the 4.3.22 section in the release notes:

============
The default rules for HTTP response codes have been simplified and made more
generic:
    1xx = Warning (when the final code received)
    2xx = OK
    3xx = Warning (except 302/303/307 = OK)
    4xx = Critical
    5xx = Critical
============

If I switch to httpstatus and configure "2.." for acceptable status
codes, the alarm goes away.  I think what happens with the regular http
test is either a bug in xymon or a documentation problem, and I'm
curious what the devs think.

Thanks,
Shawn
list Mark Felder · Mon, 23 Nov 2015 12:14:28 -0600 ·
quoted from Shawn Heisey

On Mon, Nov 23, 2015, at 12:05, Shawn Heisey wrote:
I have an http test that returns a 202 response, which was perfectly
acceptable when the xymon server was running 4.3.21.  Today I upgraded
it to 4.3.23, and now that 202 response is generating a red alarm.

Here's a relevant excerpt from the 4.3.22 section in the release notes:

============
The default rules for HTTP response codes have been simplified and made
more
generic:
    1xx = Warning (when the final code received)
    2xx = OK
    3xx = Warning (except 302/303/307 = OK)
    4xx = Critical
    5xx = Critical
============

If I switch to httpstatus and configure "2.." for acceptable status
codes, the alarm goes away.  I think what happens with the regular http
test is either a bug in xymon or a documentation problem, and I'm
curious what the devs think.
The rewritten status case statement is very clear. It absolutely should
be returning a COL_GREEN result.

I'll see if I can force something to return a 202 and see how my own
Xymon server acts.

-- 
  Mark Felder
  user-db141d317836@xymon.invalid
list Shawn Heisey · Mon, 23 Nov 2015 11:38:57 -0700 ·
quoted from Mark Felder
On 11/23/2015 11:14 AM, Mark Felder wrote:
The rewritten status case statement is very clear. It absolutely should
be returning a COL_GREEN result.

I'll see if I can force something to return a 202 and see how my own
Xymon server acts.
I think I located the problem.  This patch seems to fix it for me:

https://www.dropbox.com/s/yng89h88wad6db2/xymon-fix-http-202.patch?dl=0

Thanks,
Shawn
list Mark Felder · Mon, 23 Nov 2015 13:40:05 -0600 ·
quoted from Shawn Heisey

On Mon, Nov 23, 2015, at 12:38, Shawn Heisey wrote:
On 11/23/2015 11:14 AM, Mark Felder wrote:
The rewritten status case statement is very clear. It absolutely should
be returning a COL_GREEN result.

I'll see if I can force something to return a 202 and see how my own
Xymon server acts.
I think I located the problem.  This patch seems to fix it for me:

https://www.dropbox.com/s/yng89h88wad6db2/xymon-fix-http-202.patch?dl=0
Yep, you're 100% right. Ouch.

JC, can we get this patch committed and a release cut soon-ish?


-- 
  Mark Felder
  user-db141d317836@xymon.invalid
list Mark Felder · Mon, 23 Nov 2015 15:01:43 -0600 ·
quoted from Mark Felder

On Mon, Nov 23, 2015, at 13:40, Mark Felder wrote:

On Mon, Nov 23, 2015, at 12:38, Shawn Heisey wrote:
On 11/23/2015 11:14 AM, Mark Felder wrote:
The rewritten status case statement is very clear. It absolutely should
be returning a COL_GREEN result.
I'll see if I can force something to return a 202 and see how my own
Xymon server acts.
I think I located the problem.  This patch seems to fix it for me:
https://www.dropbox.com/s/yng89h88wad6db2/xymon-fix-http-202.patch?dl=0
Yep, you're 100% right. Ouch.

JC, can we get this patch committed and a release cut soon-ish?

Oh this appears to already have been committed. It should land in
4.3.24.


-- 
  Mark Felder
  user-db141d317836@xymon.invalid
list Japheth Cleaver · Mon, 23 Nov 2015 14:58:13 -0800 ·
quoted from Mark Felder
On Mon, November 23, 2015 1:01 pm, Mark Felder wrote:

On Mon, Nov 23, 2015, at 13:40, Mark Felder wrote:

On Mon, Nov 23, 2015, at 12:38, Shawn Heisey wrote:
On 11/23/2015 11:14 AM, Mark Felder wrote:
The rewritten status case statement is very clear. It absolutely
should
be returning a COL_GREEN result.

I'll see if I can force something to return a 202 and see how my own
Xymon server acts.
I think I located the problem.  This patch seems to fix it for me:

https://www.dropbox.com/s/yng89h88wad6db2/xymon-fix-http-202.patch?dl=0
Yep, you're 100% right. Ouch.

JC, can we get this patch committed and a release cut soon-ish?

Oh this appears to already have been committed. It should land in
4.3.24.
Hi,

Yep, discovered this much the same way. Looks entirely right until you
realize what's wrong... *sigh*. My testing was focused on errant 401's and
403's as well, which are supposed to be red anyway.

The fix seems to work for me and I haven't seen any other issues. There
are miscellaneous bug fixes throughout the 4.x stream, but nothing IMO as
critical as this; I'll roll xymon 4.3.24 up this evening for release.


Regards,
-jc