Fixed
Details
Assignee
Guus der KinderenGuus der KinderenReporter
Guus der KinderenGuus der KinderenFix versions
Priority
Medium
Details
Details
Assignee
Guus der Kinderen
Guus der KinderenReporter
Guus der Kinderen
Guus der KinderenFix versions
Priority
Created October 26, 2023 at 8:27 AM
Updated October 26, 2023 at 9:20 AM
Resolved October 26, 2023 at 9:20 AM
Openfire tries to resolve entity capabilities as soon as it sees a presence stanza that contains a CAPS hash that is doesn’t recognize. When resolving the hash, Openfire sends an IQ request (using its domain JID) to the originator of the presence stanza.
There is an issue with this in context of multi-user chat: Openfire’s requests are rejected by the MUC service, as it is not recognized as an occupant of the room in which the presence was exchanged. Errors like these are returned:
<error> <not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>You are not currently connected to this chat</text> </error>
An additional characteristic is that upon joining a MUC room, the pre-existing occupants' presence information is sent to the newly joined user, which generates a lot of presence stanzas, and thus, potential CAPS requests.
I’m not sure if resolving CAPS as soon as one is detected is a sensible approach, but at the very least, Openfire shouldn’t do this in context of MUC - it is very likely to fail, and adds considerable amount of stanza exchange upon joins.