powered by Jive Software

Disconnecting Bug Wildfire 3.2.2

When sending a message containg " " the sender gets disconnected.

Edit: This bug is new in 3.2.2. It doesn’'t happen in 3.2.0.

Hi,

are you violating the xmpp protocol by sending just “”? I really wonder whether this is allowed.

LG

No, I sent this inline. Just in a normal discussion over jabber. You can try it yourself. Just sent the text above to a contact.

What client are you using? Is the message body being xml encoded correctly?

I checked the Problem with: Psi 0.10, kopete

This is reproducable with current Wildfire SVN.

…nio.ConnectionHandler.messageReceived(session, message) gets the following as “message”:

Note there’'s no body end tag (which IS present in the stream Psi 0.10 sends - note that at least Wildfire 3.2.0 and jabberd14 work fine in the same scenario).

Therefore

Element doc = reader.read(new StringReader(stanza)).getRootElement();

in ClientStanzaHandler.process() obviously fails.

I think that’‘s a bug in Apache Mina as there seems to be no Jivesoftware code running in the stack when messageReceived() gets called but I’'m not too familiar with the whole setup.

Actually, it’‘s a bug in org.jivesoftware.wildfire.nio.XMLLightweightParser.read() I think. For some reason, when processing “item” it’'s in status INSIDE, switching to VERIFY_CLOSE_TAG when processing the /, then doing a depth-- when processing the >.

It doesn’'t need to be sent in a chat window in Psi. " /> /> " is enough (which IS XML conformant AFAIK).

SCNR: Blessings to people who write their own “lightweight” XML parsers…

Hi,

I can send these messages as often as I like - I will not be disconnected. But “” does kill the connection of the receiver.

I’'m quite sure Gato will look at this soon, create a blocker issue and fix this.

LG

it2000, the issue you describe is probably a different bug (actually I’‘m not sure this is a bug since I don’‘t know whether characters in texts need not be escaped in XML. Probably most clients escape the character as /> - Psi doesn’'t (which is perfectly XML compliant).

Hi,

I did create JM-991 - it seems that Spark/Smack is escaping /> to /> normally but not when one is using ad-hoc messages.

LG

Hey guys,

The following XML has two problems:

message to="foo" id="x"><body>ffff<item></item><item></item></body></message>
  1. The body element of a message cannot have nested elements as specified in the XMPP schema

  2. AFAIK, that is not valid XML since “ffff” is part of the TEXT of the body element and you cannot have nested elements in the text area. Therefore, you need to escape the < and > to be included there.

For those reasons we need to contact the client developers to escape < and > when including them in text areas. Anyway, I will try to make the server error-proof and consider this possible cases (though not sure if that will be possible).

Regards,

– Gato

The reason Psi does not escape ‘’>’’ is because this is actually valid XML. XMPP does not allow this, but because most clients use an off-the-shelf XML parser/generator, it’‘s probably safe to be able to handle this case. Psi 0.11 works around the XML generator we use, and escapes ‘’>’’ as well.

http://www.w3.org/TR/2006/REC-xml-20060816/#syntax

gato, XML doesn’'t require ">"s to be escaped. Also double quotes MAY be escaped only (which is broken in the old parser, too).

I created a patch to fix this issue that introduces an OUTSIDE status to the FSM. See http://phpfi.com/214152 (“license”: public domain). This also adds a simple XMLLightweightParser test class. I didn’'t do much testing apart from that and basic tests with Psi as a client. Will do more testing soon.

More testing has been done. No problems with that patch on two servers with about 100 users each. Without the patch, at least Psi and Kopete users experience disconnects if, for example, pasting XML fragments into a chat.

To repeat, this is due to Openfire 3.2.2/3.2.3 not parsing XML correctly. This is not a bug in Psi or Kopete. The error does not occur with old Wildfire versions or other server software.