I’m a developer for Digsby, and while debugging a user’s problem connecting to a recently upgraded Openfire server (3.4.3 to 3.5.1) I found the following in a vCard response.
data before being fed into the parser:
'> ’
The problem is that “& #0;” is not valid XML 1.0 (invalid character reference; not in the valid ranges for the construction of Char for XML)
This in turn breaks my parser (libxml2), which causes a disconnect.
I am aware the latest version is now 3.5.2, but looking through the commit history, I didn’t see anything that looked like it would solve the problem.
points of interest: revisions 8618 and 10506 (JM-1388) of XMLLightweightParser
Message was edited by: christopher
please note: added spaces between “&” and “#” so that it this would be visible. original data does not have a space.
The Jira issue you are referring to is about invalid surrogate characters. Is that your case too? If it is then Openfire 3.5.2 will not let a user store in the database invalid surrogate characters. If that is not your case then make sure that your database is storing things in UTF-8 format.
No, the problem is not with invalid surrogate characters. Unfortunately, the server and database in question are not mine.
I referenced the issue about surrogate characters, and invalid characters in the stream because I believe code for dealing with this will need to be added nearby.
The issue here is that Openfire has sent an invalid character reference, for which I could not find handling in your source tree. According to the XML 1.0 spec, this constitutes a violation of the well-formedness constraint. This is a fatal parser error.
When & #0; comes accross the wire, Openfire has stopped sending valid XML. It does not matter what is in the database, it is simply wrong for the server to send & #0;
Are you sure that that content came from a client? I saw that error happen when not using UTF-8 in the database. So the content that came from the client was fine but it got corrupted when storing it in the database. But maybe this is not your case.
I did create JM-884 a long time ago. Anyhow this would not help if the database corrupts the message.
One would need a validation for all incoming and outgoing messages which costs some CPU cycles. This would make Openfire a much more XMPP compliant server.