JSJaC icon indicating copy to clipboard operation
JSJaC copied to clipboard

Published 20 hours ago • verified publisher icon sstrigler

JSJaCIQ.reply cloning the request

Open gavllew opened this issue 11 years ago • 2 comments

I'm not sure if this is strictly incorrect behaviour, but thought I would bring this up as a discussion point. Are there any cases where you want the contents of the request to be duplicated in the response? I've only used iq stanzas for roster operations so far, but all that seems to be needed there is an empty iq with type='result'.

Wouldn't it be better to start with an empty iq, and just set the 'to', 'type' and 'id' attributes based on the request?

Looks like the same logic may also apply to JSJaCPacket.errorReply().

gavllew avatar May 23 '13 13:05 gavllew

Hmmm. Probably you're right, but I'm pretty sure I had sth in mind when I wrote this function (as by that time I needed it at some of my projects). Regarding errorReply the payload is definitely needed as it is common and probably good practice to send back the original request payload for easier debugging and reference.

sstrigler avatar May 27 '13 18:05 sstrigler

OK, I agree with the error replies - RFC 6120 section 8.3.1. specifies that implementations MAY include the original XML, and this makes sense.

As for normal replies, maybe provide a parameter, or a pair of helper functions - one that prepares an empty reply, and another that prepares a cloned reply.

gavllew avatar May 29 '13 09:05 gavllew