XSF Discussion - 2023-05-05

when i send a stanza over the size limit, is the stream ended by the server?

or is simply an error returned

Stream has to be ended

Well... In practice that's always going to be what happens

the stream is ended, along with all state, your user, your homework, your dog!

ALL ENDS

/s :)

what was the rational behind that?

But stream and (xep-0198) session is unrecoverable

In theory the server could read the rest of your huge stanza to /dev/null and return an error but seems funny

why not simply reject that one stanza?

How do you know it's gonna end?

What if it's an unlimited length stanza

ok, i understand, we need to abort the read, and we dont know how much else was behind that stanza

What is communicated is the hard limit. It existed already, but now you know it.

could be multiple stanzas

No behavior changes.

and then we are in an inconsistent state

Zash, the behavior changes on client side

Only that you can now take steps to avoid being brutally </stream>'d when you send something too big

i need to decide if i let a user send a stanza over the limit, or reject it

You can raise an exception earlier before the stanza actually kills the stream.

so because stream end is rather bad, the lib should not send a stanza over the limit

This was already what happened if you hit the limit.

You just got </stream>'d as a random surprise before.

yes, but my thinking was, if the server does not end the stream, simply returns an error

No

then a lib does not need to check

I don't see how this is possible with the current parser stack.

im not saying it is possible

i didnt know

nor do I want it to be possible

and i asked to decide on the behavior of the lib

Wasn't someone working on this, for nbxmpp even?

They were asking in the Prosody channel the other day.

yes i have a MR, and need to review it :)

its a rather big change, because suddenly the send() method can raise an exception when it was not possible before ..

👀

yes. those kinds of changes are "fun" to review, when the ground may change below your feet

couldn't the send() method fail before?

like, the socket turned out to have been broken or something

altho stream management could absorb that

it's async, so... it's complicated

its just much work, many parts call send_stanza() and this method did not raise exceptions, and now it does, so you need to wrap many calls in try/except blocks

mmmm, and I'm not sure I've finished all that behavior in Prosody yet. it has the same kind of problem with s2s connections

the only exceptions send() could generate before are type system related, I think :D

Even more fun, send something under your c2s limit but over your peer's s2s and get the whole s2s stream terminated for everyone!

Exceptions were a mistake :)

singpolyma, but now you can know that something is over the limit and turn it into a stanza error before sending it :)

you could do something like that internally in a client too

XEP-0478 <3

Zash: how would you know? Since the limit is set by up to two remote parties who don't tell you their limits

singpolyma, seen https://xmpp.org/extensions/xep-0478.html ?

working name "Path MTU" :)

singpolyma, if everyone supports '478 then there is no stream closure case now

Yep, very excited about that

Oh I see, that does indeed fix the s2s case I mentioned

*The XMPP Newsletter April 2023* https://xmpp.org/2023/05/the-xmpp-newsletter-april-2023/

Great job as usual emus and team

🧡