Ignite Realtime

powered by Jive Software

Ignite Realtime Community Forums

Seems to bug while parsing presense stanzas - Smack 4.1.0-rc4

Smack Smack Dev

Basav March 24, 2015, 8:44am 1

Am using Smack 4.1.0-rc4 connecting to ejabbered xmpp server. Smack throws an exception when it is unable to parse presence of a roster. The actual presence value is “online”.

Here is the xml stanza (debug mode of smack) and the Java Exception. Please note the highlighted part in blue

01:00:04 PM RECV (0):

01:00:04 PM RECV (0): onlineI am available to hear

Mar 24, 2015 1:00:04 PM org.jivesoftware.smack.AbstractXMPPConnection callConnectionClosedOnErrorListener

WARNING: Connection closed with error

java.lang.IllegalArgumentException: No enum constant org.jivesoftware.smack.packet.Presence.Mode.online

at java.lang.Enum.valueOf(Enum.java:238)

at org.jivesoftware.smack.packet.Presence$Mode.valueOf(Presence.java:329)

at org.jivesoftware.smack.packet.Presence$Mode.fromString(Presence.java:366)

at org.jivesoftware.smack.util.PacketParserUtils.parsePresence(PacketParserUtils.j ava:557)

at org.jivesoftware.smack.util.PacketParserUtils.parseStanza(PacketParserUtils.jav a:155)

at org.jivesoftware.smack.AbstractXMPPConnection.parseAndProcessStanza(AbstractXMP PConnection.java:947)

at org.jivesoftware.smack.tcp.XMPPTCPConnection.access$400(XMPPTCPConnection.java: 139)

at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.parsePackets(XMPPTCPC onnection.java:982)

at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.access$200(XMPPTCPCon nection.java:937)

at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader$1.run(XMPPTCPConnecti on.java:952)

at java.lang.Thread.run(Thread.java:745)

01:00:04 PM XMPPConnection closed due to an exception (0)

java.lang.IllegalArgumentException: No enum constant org.jivesoftware.smack.packet.Presence.Mode.online

at java.lang.Enum.valueOf(Enum.java:238)

at org.jivesoftware.smack.packet.Presence$Mode.valueOf(Presence.java:329)

at org.jivesoftware.smack.packet.Presence$Mode.fromString(Presence.java:366)

at org.jivesoftware.smack.util.PacketParserUtils.parsePresence(PacketParserUtils.j ava:557)

at org.jivesoftware.smack.util.PacketParserUtils.parseStanza(PacketParserUtils.jav a:155)

at org.jivesoftware.smack.AbstractXMPPConnection.parseAndProcessStanza(AbstractXMP PConnection.java:947)

at org.jivesoftware.smack.tcp.XMPPTCPConnection.access$400(XMPPTCPConnection.java: 139)

at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.parsePackets(XMPPTCPC onnection.java:982)

at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.access$200(XMPPTCPCon nection.java:937)

at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader$1.run(XMPPTCPConnecti on.java:952)

at java.lang.Thread.run(Thread.java:745)

thnks and rgds,

Basav

Flow March 24, 2015, 9:08am 2

The String ‘online’ is not a valid value for the text of ‘show’. See RFC 6121 4.7.2.1: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence

This is a bug in the entity generating those stanzas, so please report this to the ejabbered developers.

Basav March 24, 2015, 12:20pm 3

Thanks Flow. I will follow up with ejabbered folks and revert.

Basav March 24, 2015, 4:46pm 4

Flow,

Had a discussion with the ejabbered folks, here is the outcome.

Actually, even if the client receives a bad value here, it is supposed to ignore it according to RFC 6120 11.4 as the server has no obligation to block it:

11.4. Validation

A server is not responsible for ensuring that XML data delivered to a connected client or routed to a peer server is valid, in accordance with the definition of “valid” provided in Section 2.8 of [XML]. An implementation MAY choose to accept or send only data that has been explicitly validated against the schemas provided in this document, but such behavior is OPTIONAL. Clients are advised not to rely on the ability to send data that does not conform to the schemas, and SHOULD

ignore any non-conformant elements or attributes on the incoming XML stream.

http://xmpp.org/rfcs/rfc6120.html#xml-validation

So would it not mean that, this value needs to be ignored by Smack packet parser?

Flow March 24, 2015, 7:18pm 5

ignore any non-conformant elements or attributes on the incoming XML stream.

This is true for elements and attributes, but not for the values of defined attributes and the text content of defined elements. The reason for that is simply that you can’t ignore those. For example, assume a bad behaving entity that sends messages with type ‘furchtbar’.

<message to="someone@example.org" type=“furchtbar”…>

…

How are servers supposed to route those?

Back to the ‘show’ element of presence stanzas. RFC 6121 § 4.7.2.1. clearly states that “The XML character data MUST be one of the following…”.

I was wrong pointing you to the ejabberd developers. In the presence-show case, the server doesn’t care about the content. He is free to not validate it, and just send it to the receiver. It’s the entity where those stanzas originating from, that you need to fix.

CSH March 24, 2015, 10:00pm 6

This is true for elements and attributes, but not for the values of defined attributes and the text content of defined elements.

Hm, is it? I’d interpret it less strictly. For me online is a non-conformant element.

In any case: closing the connection is certainly the wrong answer, especially since the element is just an optional information intended mostly for human users. It’s also nowhere specified/recommended. Why not just log a warning instead?

Flow March 24, 2015, 10:07pm 7

It’s also nowhere specified/recommended.
I beg to differ: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence: RFC 6121 § 4.7.2.1 specifies the ‘show’ element.

CSH March 24, 2015, 10:15pm 8

I meant it’s nowhere specified/recommended that a client should close the connection if the stream contains a “text value for a defined element” which is not specified.

Basav March 25, 2015, 6:31am 9

+1 for CSH. Closing a connection is stringent.

Actually it is being closed because of the RuntimeException being thrown in Presence.java.

If “show” is available as per RFC, then this needs to be handled by Smack packet parser.

Could this fix go in next milestone?

Flow March 26, 2015, 7:45pm 10

That’s right, but I explained the reasons for Smack not following the robustness principle, but instead worshiping the fail fast principle by default, before. That said, nothing prevents you to use a parsing exception callback that does not cause a disconnect. You can do so since Smack 3.4 (IIRC).