http test -- 202 status red after upgrade from 4.3.21 to 4.3.23
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
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 feld at feld.me
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
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 feld at feld.me
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 feld at feld.me
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
participants (3)
-
cleaver＠terabithia.org
-
feld＠feld.me
-
hobbit＠elyograg.org