OutgoingSessionPromise is not sending error back to the client in s2s scenario
Description
Environment
Activity
Guus der Kinderen January 28, 2010 at 6:10 AM
I've worked around the issue by sending any presence-error that results from a (failed) OutgoingSessionPromise to all resources of the entity that send the original stanza.
Guus der Kinderen January 13, 2010 at 11:37 PM
Gato points out why the FROM address is overridden: this is required by the XMPP specifications. RFC 3920, section 8.2.5 reads:
The user's server MUST also stamp the presence stanza of type "subscribe" with the user's bare JID (i.e., <user@example.com>) as the 'from' address (if the user provided a 'from' address set to the user's full JID, the server SHOULD remove the resource identifier). If the contact is served by a different host than the user, the user's server MUST route the presence stanza to the contact's server for delivery to the contact (this case is assumed throughout; however, if the contact is served by the same host, then the server can simply deliver the presence stanza directly)
But also:
Note: If the user's server receives a presence stanza of type "error" from the contact's server, it MUST deliver the error stanza to the user, whose client MAY determine that the error is in response to the outgoing presence stanza of type "subscribe" it sent previously (e.g., by tracking an 'id' attribute) and then choose to resend the "subscribe" request or revert the roster to its previous state by sending a presence stanza of type "unsubscribe" to the contact.
Details
Details
Assignee
Guus der KinderenReporter
wrootIgnite Forum URL
Fix versions
Affects versions
Priority
Major
If you send a subscription request (such as subscribe) to a member on another server:
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:
We really need that error sent back to the client.