If the other server is not available then OutgoingSessionPromise will send an error back to the sender.
(This is a very important step so the client knows that the subscription failed to send.)
The code that does this is in: OutgoingSessionPromise - returnErrorToSender
The code fragment above shows that the error is routed back again.
The problem is the line: reply.setTo(from);
The “from” no longer has the resource in it because it was stripped out earlier in PresenceSubscribeHandler process.
So an error gets generated in the routePacket function. A presence can’t be routed to a bare JID and an error is generated in the WARN log:
org.jivesoftware.openfire.PacketException: Cannot route packet of type IQ or Presence to bare JID: <presence to="wolfman@jabbertest2.com" from="wolverine@jabbertest.com" type="error"> <error code="404" type="cancel"> <remote-server-not-found xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/> </error> </presence>
We really need that error sent back to the client.
Could this please be corrected in the next release.
I am currently on holidays but have just had a quick look at the source - although I can’t test anything at the moment.
The line reads:
presenteToSend.setFrom(senderJID.toBareJID());
I think its on about line 160 of PresenceSubscribeHandler.
By simply commenting out this line I no longer got the error in my post above and the error bounced back to the sender correctly.
However I am not sure that commenting it out was a good idea? as I am not sure why the sender has to be stripped to the BareJID here in the first place.
Right, got it (it’s line 168 in the current trunk):
if (!jids.isEmpty()) {
for (JID jid : jids) {
Presence presenteToSend = presence.createCopy();
// Stamp the presence with the user's bare JID as the 'from' address
presenteToSend.setFrom(senderJID.toBareJID());
routingTable.routePacket(jid, presenteToSend, false);
}
}
I’ve been reviewing the XMPP specs and SVN annotation, but I’m not finding what the reason is that we “stamp the presence with the user’s bare JID as the ‘from’ address.”
I’ve poked Gato (he’s the author of that snippet), but no reply yet.
I havent’ been able to figure out why the from-address is overridden with a bare JID. On first glance, Gato had no idea either. He was going to have a more thorough look later, but I think he didn’t get around to it. I’ll re-poke him later.
Openfire should still make sure that such an error is routed back to you. It currently does not, which is a bug (that’s why I didn’t resolve OF-23). The specs hint that Openfire should use the packet ID to trace errors that are sent back by the federated domain.