Suppress xml_parse warnings in XmlParser

[Rudloff]

If I understand correctly, the philosophy of this library is to not trigger warnings when XML is malformed, but instead use the logging mechanism.
However, xml_parse can trigger warnings when parsing some malformed strings.

For example this code:

$encoder = new \PhpXmlRpc\Encoder();
$encoder->decodeXml("<\000\000\000\au\006");

Will trigger this warning:

PHP Warning:  xml_parse(): input conversion failed due to input error, bytes 0x5C 0x61 0x75 0x06 in /home/pierre/www/fuzzer/vendor/phpxmlrpc/phpxmlrpc/src/Helper/XMLParser.php on line 263

(I am using phpxmlrpc 4.10.2.)

[gggeek]

Indeed, you might be onto something.

The lib tries to avoid echoing any error - or warning - to stdout, even in presence of malformed input, because doing so is not a good idea in general (esp. wrt security), but in particular server-side, when echoing a bunch of html back to a client expecting xml-rpc will make debugging harder than returning a well-formed xmlrpc response with a more-or-less specific error message.

The php manual page for xml_parsedoes not mention that function generating php warnings, which is the reason for not trying to silence them. I guess that in my attempts to break the xml parser with random junk I never used the correct set of entities\codepoints ;-) Or maybe this is just something which happens with specific versions of php/expat (I have seen a fair share of changes of the behaviour in xml parsing when using libxml, but it should not relate to this....)

In any case, I'll look into that - gotta decide if just silence warnings using @ or go for output-buffering instead...

Btw, what is the fuzzer in your path about?

[gggeek]

Fixed in version 4.0.3

[Rudloff]

Thanks for the explanation!

Btw, what is the fuzzer in your path about?

I used php-fuzzer to generate a value that would trigger a warning.

[gggeek]

Btw, what is the fuzzer in your path about?

I used php-fuzzer to generate a value that would trigger a warning.

Lovely! Finding unhandled corner cases via fuzz-testing is the best I could hope from library users.

Are you fuzz-testing this library in order to verify the compliance of the Polyfill, or as a general due-diligence process unrelated to it?

[Rudloff]

We are using the polyfill on a project and I wanted to check how well it resists to bogus XML.

[gggeek]

We are using the polyfill on a project and I wanted to check how well it resists to bogus XML.

Good to know. Do not hesitate to let me know if you find any other anomaly.

[gggeek]

Btw, the details about known cases where there are differences between the two libs can be found looking in https://github.com/gggeek/polyfill-xmlrpc/blob/master/src/XmlRpc.php#L12 and in https://github.com/gggeek/polyfill-xmlrpc/blob/master/tests/APITest.php (look for @todo tags, as well as breaks ... comments in data providers)