Bug 33857 - Gabble disconnects on: "Error receiving stanza: Namespace prefix xmlns on server is not defined "
Gabble disconnects on: "Error receiving stanza: Namespace prefix xmlns on ser...
Product: Telepathy
Classification: Unclassified
Component: gabble
Other All
: medium normal
Assigned To: Telepathy bugs list
Telepathy bugs list
Depends on:
  Show dependency treegraph
Reported: 2011-02-02 19:34 UTC by Danielle Madeley
Modified: 2011-06-06 01:44 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Note You need to log in before you can comment on or make changes to this bug.
Description Danielle Madeley 2011-02-02 19:34:16 UTC
* iq xmlns='jabber:client' type='get' to='sam.badger@badger.com' id='134813220909'
    * pubsub xmlns='http://jabber.org/protocol/pubsub'
        * items node='http://jabber.org/protocol/geoloc'
wocky-DEBUG: 03/02/11 15:10:34.225430: _error: wocky-xmpp-reader.c:602: Parsing failed Namespace prefix xmlns on server is not defined
wocky-DEBUG: 03/02/11 15:10:34.225467: _end_element_ns: Received stanza
* presence xmlns='jabber:client' from='nick.badger@badger.com/iTeleport Connect.MAC.7EA2DE9A' to='tom.badger@badger.com/6e399af8'
    * nick xmlns='http://jabber.org/protocol/nick'
    * type
    * id
    * server
    * show
    * invisible value='true'
    * priority
    * name
        "iTeleport Connect"
    * version
    * ssh-enabled
    * automanage-vnc
    * encryption-enabled
    * x xmlns='vcard-temp:x:update'
        * photo
wocky-DEBUG: 03/02/11 15:10:34.225476: stanza_received_cb: wocky-porter.c:1202: Error receiving stanza: Namespace prefix xmlns on server is not defined
gabble/connection-DEBUG: 03/02/11 15:10:34.225533: remote_error_cb: Force closing of the connection 0x12780d0
wocky-DEBUG: 03/02/11 15:10:34.225632: wocky_porter_force_close_async: wocky-porter.c:1849: remote is already closed, close the XMPP connection
Comment 1 Catalin Patulea 2011-06-03 21:24:58 UTC
Hitting this with 0.10.0 with a similar stanza.

Looks like the problem is a malformed tag in the iTeleport stanza:

$ cat /tmp/stanza.xml 
<presence from="trivex@gmail.com/iTeleport Connect.MAC.71AE9956" to="cronos586@gmail.com/10719d02">
  <nick xmlns="http://jabber.org/protocol/nick">tw-growth-pair</nick>
  <type xmlns="">MAC</type>
  <id xmlns="">vnc</id>
  <xmlns:server xmlns="http://www.w3.org/2000/xmlns/"/>
  <server xmlns=""/>
  <invisible value="true"/>
  <name xmlns="">iTeleport Connect</name>
  <version xmlns="">5.0.10</version>
  <ssh-enabled xmlns="">false</ssh-enabled>
  <automanage-vnc xmlns="">true</automanage-vnc>
  <encryption-enabled xmlns="">true</encryption-enabled>
  <router-mac-address xmlns=""/>
  <x xmlns="vcard-temp:x:update">

$ python -c 'import libxml2; libxml2.parseFile("/tmp/stanza.xml")'
/tmp/stanza.xml:5: namespace error : reuse of the xmlns namespace name is forbidden
  <xmlns:server xmlns="http://www.w3.org/2000/xmlns/"/>
/tmp/stanza.xml:5: namespace error : Namespace prefix xmlns on server is not defined
  <xmlns:server xmlns="http://www.w3.org/2000/xmlns/"/>

The W3C recommendation on namespaces (http://www.w3.org/TR/REC-xml-names/#ns-decl) says that you can't redeclare the 'http://www.w3.org/2000/xmlns/' namespace, which is what that 'xmlns:server' tag is trying to do.

It's not clear to me whether this is a bug in iTeleport, the Google XMPP server implementation, Gabble, or all of the above:

* iTeleport definitely shouldn't be sending out malformed XML.
* Google XMPP should (?) not accept malformed XML from its clients.
* Gabble should gracefully handle this type of error, and ignoring the presence IQ, rather than crashing entirely.

Is this fixed in newer versions of gabble?
Comment 2 Catalin Patulea 2011-06-03 23:15:30 UTC
Looks like this was fixed in wocky commit f2cb0f6f:

The first telepathy-gabble commit to pull this in from wocky was 50a69455:

For the 0.10 branch this means it's fixed in >= 0.10.2.
Comment 3 Simon McVittie 2011-06-06 01:44:41 UTC
Fixed in 0.10.2 and all subsequent versions, thanks for your research.

Please note that the current stable branch is 0.12.x, and 0.10.x is unlikely to receive further bug fixes.