Skip to content

Conversation

ps-cwitte
Copy link

ilert returns a HTTP 400 if there are restricted XML characters anywhere in the request. This fix removes such characters from any payload entry.

@Harry-Pootha
Copy link

Harry-Pootha commented Oct 14, 2025

To elaborate:

We have a Service in Icinga where a PowerShell script is used for verifying the service state. When the script runs into an error (read Exception) PowerShell tends to print these errors in red. This is done by using regular ANSI control characters.

For example:
\e[31;1mOperationStopped: \e[31;1m503: Service Unavailable -- <could not parse response content>\e[0m

The output from the Shell is taken by Icinga as is, including the ANSI characters. This is also the value sent to ilert via the API. Upon receiving the string the API rejects the request because the XML is seen as invalid.

Looking at the W3C Recomendation (here) there is a range of characters the use of is "discouraged".


This PR removes the whole range of unsupported characters. When applying the Regex from the PR using the example string above it results in this:
[31;1mOperationStopped: [31;1m503: Service Unavailable -- <could not parse response content>[0m

Note the control characters have been removed.


There is the slight caveat that only single characters are checked and removed. The full control sequence [31;1m still persists.

This could be caught as well if needed. To do so the regex needs to be extended. A first test with this regex works:

_illegal_xml_chars_RE = re.compile(u'[\x00-\x08\x0b\x0c\x0e-\x1F\uD800-\uDFFF\uFFFE\uFFFF](?:[@-Z\\-_]|\[[0-?]*[ -/]*[@-~])')

(taken from here)

Result:
OperationStopped: 503: Service Unavailable -- <could not parse response content>

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants