Jive Server sending malformed XML <iq/> packet

Openfire Openfire Support
1

Hi,



I have found a bug with the latest version of Jive running as a windows service. It has to do with sending out an packet that is malformed which is causing my client to not be able to parse the XML once received.



The packet being sent by Jive is as follows:



</i>



(notice the closing tag “</i>”, it should be )



Basically this is caused by sending out a presence request of subscribe to another JID:



<-- Sent -->

<-- end -->

<-- Recv Time:1113344763982 -->

<-- end -->

<-- Recv Time:1113344764076 -->

bridgeUser

<-- end -->



it causes the server to send the malformed XML to the bridge@xmpptest.partners.org user.



Let me know if you know how to fix this.



Thanks,

Chris

Message was edited by:

callen

**note due to HTML and emoticons it was difficult to write out the XMPP packets being sent. I can email it to you if want the complete example.

2

I’'m surprised that none of the developers have responded to this yet, It seems like a significant problem with the server as it is not XMPP compliant nor even valid XML. I also spotted another poorly formatted XMPP node last night.

Notice no closing slash here. I suppose most clients are ignoring the fact that there is no closing slash, but I’‘m trying to parse it as XML in my application and it simply doesn’'t work for me.

If I figure out where to make the changes in the code and compile it myself and get it to work correctly who do I let know about this?

Thanks for any feedback.

-Chris

3

Chris,

I apologize for not getting back to you earlier. Because of the way we create XMPP packets, it should be virtually impossible for invalid packets to get created. However, anything is possible. In this latest case, that looks like a packet coming from a client to another client. The former case is server to client, though. What client are you using? Can you verify this same behavior with other clients?

Regards,

Matt

4

Chris,

I apologize for not getting back to you earlier.

That’'s okay.

Because of the way we create XMPP packets, it should

be virtually impossible for invalid packets to get

created. However, anything is possible. In this

latest case, that looks like a packet coming from a

client to another client. The former case is server

to client, though.

These two are both server to client. I am fairly certain (99%) that they are coming from Jive Messenger just as I describe here. But as you say above, “anything is possible”.

What client are you using?

I’‘m using two different clients that we have created here at MGH. The first is a RIA Macromedia Flash client that utilizes Sean Voisen’‘s XIFF library. The other is a Java application that acts as a proxy for all messages to convert the socket XMPP message into an http request that then get’'s processed by ASP.

Can you

verify this same behavior with other clients?

Yes, I have seen the same thing happen using Exodus. Exodus simply writes out the following in the debug window when receiving the bad node:

“Unknown notify event: /presence/subscription”

As for the presence node, it seems to convert it to have a closing slash and has no problem parsing it.

I have also tested this by creating a very simple client using XIFF and flash that receives messages and I see the behavior there too.

Regards,

Matt

Let me know what else I can do to help.

Thanks,

Chris

5

Hi Matt,

I spent a bunch of time trying to debug this little problem and it turns out that it is not Jive Messenger that is causing the problem. I’'m very sorry to have reported a bug that was not even there.

The problem turns out to be in our Java middle-ware client. It seems to be stripping some of the characters out of the message before sending along to the rest of the application.

Once again sorry for the misinformed post and thanks for creating an open source XMPP server which appears to be working well for a few days straight now.

-Chris

6

Chris,

Glad you found the issue, because we were definitely stumped.

Regards,

Matt