XI 5.7.2 stripping html tags from service status messages

[umunix]

Hi nagios folks,

After upgrading to 5.7.2 I noticed that some of our http alerts that include a link in the status, are missing the closing tag </a>. As a result of this, all the remaining links on the service status page are broken, as well as in our email notifications.

The check itself generates the link correctly, but the end tag for the link </a> disappears somewhere when it makes its way into Nagios.

./check_http -H hostname -p 7053 -u /url/ -e 'HTTP/1.1 401' -f stickyport -L -w 10 -c 30
<A HREF="http://hostname:7053/url/" target="_blank">HTTP OK: Status line output matched "HTTP/1.1 401" - 1657 bytes in 0.010 second response time </A>|time=0.009569s;10.000000;30.000000;0.000000 size=1657B;;;0

We are running an older installation that still uses postgres, which perhaps may be relevant to this problem.

Kind regards,
Richard

[umunix]

My apologies, the problem is actually with the check_http plugin.

The missing tag actually appears to be a result of the check_http plugin truncating status output under certain conditions, for example:

# ./check_http -H google.ca -L
<A HREF="http://google.ca:80/" target="_blank">HTTP OK: HTTP/1.1 301 Moved Permanently - 545 bytes in 0.126 second response time </A>|time=0.126334s;;;0.000000 size=545B;;;0

# ./check_http -H google.ca/blahblah -L
<A HREF="http://google.ca/blahblah:80/" target="_blank">check_http: Invalid hostname/address - google.ca/blahblah


Richard

[lmiltchev]

Instead of running this:

Code: Select all

./check_http -H google.ca/blahblah -L

try running something like this:

Code: Select all

./check_http -H google.ca -u https://google.ca/blahblah -L

https://linux.101hacks.com/unix/check-http/

Did this help?

[umunix]

Thanks for the reply, your suggestion did fix the problem with my example. I also apologize that my example wasn't a very good one given I wasn't even using the check correctly.

I did however take a closer look at the checks that we were noticing the problem on, and I believe the problem may be to our use of this option:
-e, --expect=STRING
Comma-delimited list of strings, at least one of them is expected in
the first (status) line of the server response (default: HTTP/1.)
If specified skips all other status line logic (ex: 3xx, 4xx, 5xx processing)

For example:

When the -e condition is satisfied the link is closed properly, however it isn't when the condition is not satisfied. For example:

# ./check_http -H google.ca -u /doesntexist -L -e 'HTTP/1.1 404 Not Found'
<A HREF="http://google.ca:80/doesntexist" target="_blank">HTTP OK: Status line output matched "HTTP/1.1 404 Not Found" - 1746 bytes in 0.052 second response time </A>|time=0.051524s;;;0.000000 size=1746B;;;0

# ./check_http -H google.ca -u /doesntexist -L -e 'HTTP/1.1 403 Not Found'
<A HREF="http://google.ca:80/doesntexist" target="_blank">HTTP CRITICAL - Invalid HTTP response received from host: HTTP/1.1 404 Not Found

[swolf]

Hello @umunix,

I can confirm that this isn't expected behavior. nagios-plugins is due for another bugfix release in the next couple of months - I've made a note to look into this at that time.

As a workaround, I would recommend using -U, which will print out the full URL in the status message.

Please let us know if you have other concerns or need further clarification on anything.