Control Characters killing client connection

Hello everybody,

I recently developed a plugin with some custom IQs.

One such IQ accepts a base64 encoded HTML.

The plugin now decodes the HTML and runs a regex (to remove HTML tags) and then gets the first 100 chars and the nsaves that result as PlainText into the DB…later on the client can request the info again…and it will get send as plaintext…

The problem is that I tested with control chars such as these:

≈♦⇔→•

…when the plugin now tries to send this then my clients connection is completely broken.

It seems related to this -> https://igniterealtime.org/issues/browse/OF-455

I would like to know how openfire handles this…I was told to use StringUtils.escapeForXML …it does help for those chars mentioned above…but now I am running into trouble with these bad boys -> ŷ►‛

Is there any way for me to get rid of those chars bevore trying to send my IQ?

Thanks in advance

Could you show us the Openfire Exception that’s causing the disconnect? Or could you elaborate “running into trouble”?

The wierd thing is that there is no internal exception or anything.

The plugin will try to send the IQ …and once the this.send(IQ) method is called the user simply looses his connection. We have this happening on android, ios and the web …when I remove the malicious characters everything is fine.

Is there maybe another “cleanup” command?

If you can rule out that the clients are closing the conneciton, then I suggest you attach an debugger to openfire and trace the send method to determine the cause.

Its a pretty complex environment thats needed for our plugins to work in harmony… its a productive version of openfire that we got running…unfortunately I cant attach a debugger atm

Does openfire support the in its stanzas?

CDATA are not a solution if you can’t gurantee that their content will never contain the following three characters in order ‘]’, ‘]’, ‘>’. I suggest you encode the binary data with base64 put the encoded binary data as text of an element. That’s how it’s done all over the place in XMPP.

We used base64 before…but certain characters (control characters) killed the base64 somehow.

We’ll give it a try again.

Thanks for the help.