What steps will reproduce the problem?
1. Receive bogus XML in the input stream from the server.
We encountered this at StatusNet when changing servers from ejabberd to
Prosody; Prosody 0.6 would send us malformed XML such as this fragment:
< xmlns="date">...</>
(This bad output is a bug in Prosody triggered by some edge cases in input
from other clients, fixed in dev branch:
http://hg.prosody.im/0.6/rev/13d55c66bf81 )
What is the expected output? What do you see instead?
We would expect to see an error message in the debug log output (if
enabled), and probably an exception thrown.
Instead we saw silent failure: XML input continued to come in from the
server and was dutifully logged with 'RECV:' lines (in verbose mode), but
our code saw no incoming messages on its callbacks.
When the read buffer containing a broken stanza is run through xml_parse(),
the XML parser refuses to parse any further, so no more incoming messages
of any type get processed. Since an XML error in xml_parse() triggers no
exception, PHP error, or PHP warning, there is no indication that
anything's wrong without checking the return value.
Attached patch against r77 checks for XML parse errors, logs them with
'error' level, and throws an exception.
What version of the product are you using? On what operating system?
r76 (not affected by changes in r77) on PHP 5.2.6 on Ubuntu 9.04/x86_64
Original issue reported on code.google.com by brion.vi...@gmail.com on 20 Jan 2010 at 10:56
Original issue reported on code.google.com by
brion.vi...@gmail.comon 20 Jan 2010 at 10:56Attachments: