Looking for ejabberd docs?

To access the most up-to-date ejabberd documentation, please visit docs.ejabberd.im »

2.1 Beta Pubsub invalid-payload

Submitted by Chris Hagan on Tue, 2009-09-01 08:03

ejabberd Development

Hi all,

I'm just trying an existing client which worked perfectly against 2.0.5 against the new 2.1 beta with the intention of utilizing the apparently much improved pubsub. On attempting to post a message to my node I'm being rejected with

<iq xmlns="jabber:client"
    type="error"
    from="pubsub.civic.adm.monash.edu"
    to="0@civic.adm.monash.edu/agsXMPP"
    xml:lang="en"
    id="agsXMPP_14">
  <pubsub xmlns="http://jabber.org/protocol/pubsub">
    <publish node="/home/civic.adm.monash.edu/0">
      <item>MESSAGE GOES HERE</item>
    </publish>
  </pubsub>
  <error type="modify" code="400">
    <bad-request xmlns="urn:ietf:params:xml:ns:xmpp-stanzas" />
    <invalid-payload xmlns="http://jabber.org/protocol/pubsub#errors" />
  </error>
</iq>

To my reading this implies that the namespaces don't match between the item and the pubsub... Um, the pubsubby thing. Some mismatch, anyway. This seems to have some correlation with
https://support.process-one.net/browse/EJAB-117
which includes a discussion in which it is stated that:

"The pubsub JEP 0060 has been published in version 1.8 has been published at the end of june 2006.
Several things have changed. For example some namespaces have been renamed:
* nodes deletion was using namespace "http://jabber.org/protocol/pubsub". It now use namespace "http://jabber.org/protocol/pubsub#owner"."

and that

"This fix will broke when applied client using pubsub:
We will do the change in version 2.1 and warn users in the changelog of version 2.0 that this is the last release supporting the XEP-001.7."

Can anybody please confirm that this is a breaking change in 2.1? I would also very much appreciate advice on how to conform to the new expected format of a pubsub payload.

Thanks!

A similar example works for

Submitted by mfoss on Tue, 2009-09-01 12:40.

A similar example works for me.

I installed ejabberd 2.1.0-beta2, created an account, logged in, and then followed the second example found in
How to use ejabberd's pubsub module. The one that says "Example for 2.1.0 with plugin "flat"."

I have this in ejabberd.cfg

{modules, [
  ...
  {mod_pubsub,   [
                  {access_createnode, pubsub_createnode},
                  {pep_sendlast_offline, false},
                  {last_item_cache, false},
                  {plugins, ["flat", "pep"]}
                 ]},
  ...
]}.

In your case, as you want to continue using the "/home/SERVER/USERNAME" paths, you can add this plugin to the mod_pubsub option: "hometree"

Thanks, I'll try that this

Submitted by Chris Hagan on Wed, 2009-09-02 03:29.

Thanks, I'll try that this morning.

(Later that morning):

Following the example you provided, I've changed my pubsub config to 'flat', so that now the node name is simply "/mr0". The node is created without error and is discoverable through Psi. However trying to publish to it (using agsXmpp) sends the stanza:

<iq id="agsXMPP_5" type="set" to="pubsub.civic.adm.monash.edu"><pubsub xmlns="http://jabber.org/protocol/pubsub"><publish node="mr0"><item>0:STROKE</item></publish></pubsub></iq>

Which elicits a response of:

<iq xmlns="jabber:client" type="error" from="pubsub.civic.adm.monash.edu" to="0@civic.adm.monash.edu/agsXMPP" xml:lang="en" id="agsXMPP_5"><pubsub xmlns="http://jabber.org/protocol/pubsub"><publish node="mr0"><item>0:STROKE</item></publish></pubsub><error type="modify" code="400"><bad-request xmlns="urn:ietf:params:xml:ns:xmpp-stanzas" /><invalid-payload xmlns="http://jabber.org/protocol/pubsub#errors" /></error></iq>

This seems to me to be behaving the same way as before. Is my publish stanza correctly constructed? Thanks for your help.

EDIT:

By changing my node in the publish tag to "pubsub.civic.adm.monash.edu/mr0" the error has become a 404: Item not found. I'm not sure whether this is an improvement, but it certainly seems that the earier error is pretty much the response to any nonsensical item; a stanza whose node is "NONSENSE" will result in the same 400, for instance, so the 404 seems like it might be better?

EDIT:

Probably not an improvement. None of the tutorials use qualified node names. Also the XEP doesn't mention 404s, although the meaning is fairly clear.

SOLVED

Submitted by Chris Hagan on Wed, 2009-09-02 05:43.

We have now successfully published against 2.1.

Turns out the issue was that the item node must contain an entry node, the namespace of which must explicitly be 'http://www.w3.org/2005/Atom'. This is confusing, as the XEP0060 error spec goes:

<iq type='error'
    from='pubsub.shakespeare.lit'
    to='hamlet@denmark.lit/elsinore'
    id='publish1'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <publish node='princely_musings'>
      <item id='ae890ac52d0df67ed7cfdf51b644e901'>
        ... INVALID PAYLOAD ...
      </item>
    </publish>
  </pubsub>
  <error type='modify'>
    <bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
    <invalid-payload xmlns='http://jabber.org/protocol/pubsub#errors'/>
  </error>
</iq>

It would be more informative to a beginner like me to have it read:

<iq type='error'
    from='pubsub.shakespeare.lit'
    to='hamlet@denmark.lit/elsinore'
    id='publish1'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <publish node='princely_musings'>
      <item id='ae890ac52d0df67ed7cfdf51b644e901'>
         <entry xmlns='...INVALID NAMESPACE...'>
            ...INVALID PAYLOAD...
         </entry>
      </item>
    </publish>
  </pubsub>
  <error type='modify'>
    <bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
    <invalid-payload xmlns='http://jabber.org/protocol/pubsub#errors'/>
  </error>
</iq>

Anyway, that's fixed. Thanks to everyone who looked on and particularly to badlop for helping.

Pubsub bug reports

Submitted by Liam on Tue, 2009-10-20 23:41.

In 2.1.0-rc1...

1) The node config form does not include <field var='pubsub#type'/> -- let alone define that as Atom. The pubsub module should allow configuring this field.

2) The pubsub spec doesn't specify Atom as the default node namespace. The spec is silent on what payload namespaces are allowed if pubsub#type is undefined, but the obvious answer is ANY, including plain text. The pubsub module should allow that.

3) The spec permits multiple <item> elements in a publish request, and that doesn't work for me in rc1.

I paste here initial replies

Submitted by mfoss on Wed, 2009-10-21 17:11.

I paste here initial replies provided by Christophe Romain. If they don't solve the questions, you can submit your questions as tickets in the bug tracker, and they will get more detailed analysis.

Replies:

1) pubsub#type was, at the begining of plugin implementation, mapped with node plugin name. I think this is not used anymore. I'd have to check this. pubsub#type is allowed in form. I just think it's informative only (not linked with anything).

2) Not including plain text.

3) Multiple items is bad idea and I think this have been removed in 1.13

Tracked in

Submitted by mfoss on Wed, 2009-10-21 18:08.

Tracked in https://support.process-one.net/browse/EJAB-1083

Fix in progress

Submitted by Liam on Wed, 2009-10-21 23:37.

Thanks for resolving this in rc3!