[Xymon] Regex escaping in 'cont=' test
Ralph Mitchell
ralphmitchell at gmail.com
Sat Oct 7 04:37:15 CEST 2017
Took the quotes out, had to change the space to \x20 to get it to show in
the info page.
So, server/etc/hosts.cfg is now essentially the same as yours, but with the
<:
192.168.1.4 xxxx.yyyy.com # cont;http://xxxx.yyyy.com/test.html
;<a\x20href=\x22foo/bar\x22>
source of the info page looks like this:
<tr><th align=left>Content checks:</th><td align=left>
<a href="http://xxxx.yyyy.com/test.html">http://xxxx.yyyy.com/test.html</a>
must return '<a href="foo/bar">'<br>
</td></tr>
test.html contains:
<a href="foo/bar">
content test shows green. In test.html, changed foo to fop, test went
red. Changed < to dot, test went red.
Maybe the parser is broken in your version and fixed in mine, or vice
versa?? I'm running Xymon 4.3.28-rc2 on CentOS 7.
Ralph Mitchell
On Fri, Oct 6, 2017 at 1:45 PM, John Thurston <john.thurston at alaska.gov>
wrote:
> With eager fingers, I went to adjust my hosts.cfg, and .. ... no diff.
> I've tried both single and double quotes. Single quotes caused nothing to
> be parsed from the cont= tag. Double quotes made no difference in behavior.
>
> Maybe this is another oddity stemming from my ancient OS and underlying
> libraries. (Solaris 10)
>
> Do you see the behavior I described if you _don't_ wrap in quotes?
>
> --
> Do things because you should, not just because you can.
>
> John Thurston 907-465-8591
> John.Thurston at alaska.gov
> Department of Administration
> State of Alaska
>
> On 10/6/2017 9:21 AM, Ralph Mitchell wrote:
>
>> Did you try quoting the entire 'cont;URL;[expected_data]" string?
>>
>> I just tried this:
>>
>> 192.168.1.4 xxxx.yyyy.com <http://xxxx.yyyy.com> #
>> "cont;http://xxxx.yyyy.com/test.html <http://xxxx.yyyy.com/test.html>;<a
>> href=\x22foo/bar\x22>"
>>
>> and the page source for the "info" column shows:
>>
>> <tr><th align=left>Content checks:</th><td align=left>
>> <a href="http://xxxx.yyyy.com/test.html
>> <http://xxxx.yyyy.com/test.html>">http://xxxx.yyyy.com/test.html
>> <http://xxxx.yyyy.com/test.html></a> must return '<a
>> href="foo/bar">'<br>
>> </td></tr>
>>
>> so you can see it picked up the whole '<a href="foo/bar">' string. The
>> test.html file on the server contains nothing but the opening and
>> closing html/body tags, and the match string. If I change "foo" to
>> "fod" in test.html, the match fails and if I change the leading "<" to a
>> comma, the match also fails
>>
>>  http://xxxx.yyyy.com/test.html - Testing URL yields:
>>
>> ,a href="foo/bar">
>>
>> Ralph Mitchell
>>
>>
>> On Wed, Oct 4, 2017 at 4:55 PM, John Thurston <john.thurston at alaska.gov
>> <mailto:john.thurston at alaska.gov>> wrote:
>>
>> I'm fighting with the correct escaping and encoding for http content
>> checks using the "cont=" tag:
>>
>> cont[=COLUMN];URL;[expected_data_regexp|#digesttype:digest]
>> This tag is used to specify a http/https check, where it is also
>> checked that specific content is present in the server response.
>>
>> . . .
>>
>> The regex is pre-processed for backslash "\" escape
>> sequences. . .
>>
>>
>> I can't find the expression to match the string:
>> <a href="foo/bar">
>> (Which I hope your email client isn't going to try to render as html!)
>>
>> The closest I can manage is:
>> a\x20href=\x22foo/bar\x22>
>>
>> Where \x20 is an ASCII space, and \x22 is a double-quote
>>
>> If I put a leading \x3D (which is an equal-sign), that renders in
>> the search string and obviously doesn't match my supplied content.
>> If, however, I put a leading \x3C (which is the less-than sign) the
>> rest of the expression is eaten and is not rendered. I've tried
>> leading the \x3C with \x5C (which is a backslash), with no effect.
>>
>> I also tried leading with \x5C\x78\x33\x43 (which is \x3C), which
>> renders as such, but does not match my string.
>>
>> The upshot is, I can match enough of my string to be unique on my
>> page. But it seems like something isn't right in the regex escaping
>> and cleansing for this test. The supplied string should be accepted
>> as a string, but the "<" seems to be interpreted during the parsing
>> instead.
>>
>> Can anyone else find a way to use a "<" in the regex of the cont=
>> test?
>>
>>
>> --
>> Do things because you should, not just because you can.
>>
>> John Thurston 907-465-8591 <tel:907-465-8591>
>> John.Thurston at alaska.gov <mailto:John.Thurston at alaska.gov>
>> Department of Administration
>> State of Alaska
>>
> _______________________________________________
> Xymon mailing list
> Xymon at xymon.com
> http://lists.xymon.com/mailman/listinfo/xymon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20171006/a1a2c624/attachment.html>
More information about the Xymon
mailing list