-
Actually after reading https://xmpp.org/extensions/xep-0050.html#impl-commands and https://xmpp.org/extensions/xep-0133.html#errors I'm not 100% sure that returning IQ with type=error would be correct. First link mentions:
The status of command execution signals only if the command is executing, has been completed, or been canceled. If completed, the "status" attribute does not specify if it completed successfully or not. If a command completes but fails, the responder MUST include at least one with the it returns.
but it doesn't indicate that IQ should be of type=error. Considering semantics it seems that we would have to: set IQ type to error, include an
<error/>
child and on top of that still include<note type='error'/>
within command element. Probably worth checking out with XSF, though I'd be leaning towards returning IQ type=error here as it makes more sense.
Type |
Task
|
Priority |
Normal
|
Assignee | |
Version |
Candidate for next major release
|
As commented in https://projects.tigase.net/issue/issue #1177#focus=Comments-4-27558.0-0, we currently always return
type=result
even if the command failed. Evaluate (and implement if possible) change to correctly return IQ type=error.This will affect our REST - API most likely (it should return relevant 4xx codes IMHO) and possibly some clients.