We're updating the issue view to help you get more done. 

OutgoingSessionPromise is not sending error back to the client in s2s scenario

Description

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.

Environment

None

Acceptance Test - Entry

None

Activity

Show:
Guus der Kinderen
January 13, 2010, 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.

Guus der Kinderen
January 28, 2010, 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.

Assignee

Guus der Kinderen

Reporter

wroot

Labels

None

Expected Effort

None

Fix versions

Affects versions

Priority

Major
Configure