#438 Smack MUC extension is broken on room creation, maybe other cases

Reporter Waqas
Owner Waqas
Created
Updated
Stars ★★ (2)  
Tags
  • Interoperability
  • Type-Defect
  • Status-Fixed
  • Priority-Medium
  1. Waqas on

    MUC presence can have multiple status codes. For example a room creating presence response has both status code 110 (it's your own presence) and 201 (it's a room creation presence): http://xmpp.org/extensions/xep-0045.html#example-154 Smack code assumes there's just one status code in muc#user presences. Smack picks the last status code. When creating a room with Smack, Prosody sends 201, 110. Smack finds that the last status is 110, not 201, and throws an exception. Relevant Smack code is here: https://github.com/igniterealtime/Smack/blob/6a43fc7c36b22b1d050cdfe7b4ab715a58da540c/smack-extensions/src/main/java/org/jivesoftware/smackx/muc/MultiUserChat.java#L396 The relevant Smack code was committed on 2004-07-06. The XEP may have been different back then, though probably not. Issue known to occur with prosody-trunk. Older Prosody sent statuses in a different order in the room-create case.

  2. Waqas on

    "Added status codes for occupant's own roomnick, service-modified roomnick, and warning that room discussion is publicly logged." - Version 1.21 (2006-09-13)

  3. fschmaus on

    Related Smack Issue: https://igniterealtime.org/issues/browse/SMACK-604

  4. MattJ on

    According to that link, this issue was fixed in Smack in 4.1.0. Closing this.

    Changes
    • tags Status-Fixed

New comment