jdev - 2020-08-05

hm after reading the rfc

if i send an IQ to a server without a "to" attribute

My favourite topic!

server needs to treat like my bare jid?

because the rfc text is a bit cryptic

lovetox, yes

ok nice

but implementations vary :)

be aware that you might get your IQ back with a @to attribute

instead of without

so your reply matchers have to treat @to=localBareJID identical to absent @to

%s/@to/@from/g, sorry ✏

yes, actually i do this very early after stanza parsing

if there is to or from missing

:+1:

then you should be good

i fill in te respective values the rfc says

and then you have the missing @to in carbons

My opinion: clients should never use the 'to' attribute of incoming stanzas

because i simply dont want to deal with absent from / to later in my code

But I can understand why the missing/different 'from' trips implementations up

yeah incoming from is obviously important

i asked about outgoing to

MattJ, yes, it was a typo ✏

because i spares me to always look up my bare jid

on the various PEP operations

I don't have the RFC to hand, but last time I looked it up I decided that if a server stamps a bare JID as the 'from' of a reply to to a stanza that has no 'to', that is not allowed, and therefore a bug.

So > But I can understand why the missing/different 'from' trips implementations up Clients are allowed to be tripped up by this, because it's illegal.

Although ISTR there is at least one case where, although the server has to treat no to and bare JID as the same, one of the protocols requires that it be no to rather than bare JID for no good reason.

Kev, which case is that?

I don't recall, sadly.

re the first part: I only cound find the following stanza error rule: 2. The error stanza SHOULD simply swap the 'from' and 'to' addresses from the generated stanza,

so I am not sure if I would call the behavior you described above a bug

missing from attribute is allowed

When the server generates a stanza from the server for delivery to the client on behalf of the account of the connected client (e.g., in the context of data storage services provided by the server on behalf of the client), the stanza MUST either (a) not include a 'from' attribute or (b) include a 'from' attribute whose value is the account's bare JID

and i think thats the case MattJ was thinking about

flow: You might be right. It might be that type=result doesn't mandate that, only type=error.

lovetox: Yes, missing from is definitely allowed.

i wonder why this was made that way

it seems really not worth it, its not expected that a big percentage of all traffic is from server to client in a account context

lets save 20 bytes on every 50th message

but makes it very easy to be tripped up as a developer

jonas’, im looking again trhough aioxmpp

and i see you raise an exception when a IQ error is returned

i guess i look into jabbercat how this looks in a client code

i had the same thought, for my library, to raise exception

but i wonder how nice this is for client developers

especially for iq errors

eta, whats the lib you are writing?

lovetox: the component library used by whatsxmpp

(which isn't really a fully separate thing yet)

what language?

lovetox: Common Lisp :)

relevant code: https://git.theta.eu.org/eta/whatsxmpp/src/branch/master/component.lisp#L258

yeah never got into Lisp so i probably need a week to even understand a bit of the code

reasonable :p

why i wonder in python about exceptions is

not on all iq errors you want to simply abort and be finished

sometimes you expect this case and do other stuff because of the error

and then you have to do all that in an exception block

lovetox: wait is your IQ thing blocking

which is weird, becuase if it raises again exceptions, then you get this super long traceback

like is it synchronous or asynchronous

while an exception was raised, another exception was raised, and another exception was raised..

oh, I guess Python has async/await now, nvm

well, this is what multiple return types / Rust's Result type is for

like, returning (result, error)

yeah i do this right now, there is one result, and user can check if it was an error or a normal result

and can then do his stuff

sounds good

yeah maybe im overthinking this :)

i guess there is not only one good way

especially with exceptions there are two camps

only 2? I'm counting checked exceptions, runtime exceptions, checked+runtime exceptions, and no exceptions :)

heh :)

lovetox, exceptions are amazing for IQ errors

you can write a chain of IQ calls and wrap it in a single try/except aioxmpp.XMPPError block for example