XSF Discussion - 2023-05-05

  1. lovetox

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

  2. lovetox

    or is simply an error returned

  3. moparisthebest

    Stream has to be ended

  4. moparisthebest

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

  5. Zash

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

  6. Zash


  7. Zash

    /s :)

  8. lovetox

    what was the rational behind that?

  9. Zash

    But stream and (xep-0198) session is unrecoverable

  10. moparisthebest

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

  11. lovetox

    why not simply reject that one stanza?

  12. moparisthebest

    How do you know it's gonna end?

  13. moparisthebest

    What if it's an unlimited length stanza

  14. lovetox

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

  15. Zash

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

  16. lovetox

    could be multiple stanzas

  17. Zash

    No behavior changes.

  18. lovetox

    and then we are in an inconsistent state

  19. lovetox

    Zash, the behavior changes on client side

  20. Zash

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

  21. lovetox

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

  22. Zash

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

  23. lovetox

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

  24. Zash

    This was already what happened if you hit the limit.

  25. Zash

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

  26. lovetox

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

  27. Zash


  28. lovetox

    then a lib does not need to check

  29. Zash

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

  30. lovetox

    im not saying it is possible

  31. lovetox

    i didnt know

  32. Zash

    nor do I want it to be possible

  33. lovetox

    and i asked to decide on the behavior of the lib

  34. Zash

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

  35. Zash

    They were asking in the Prosody channel the other day.

  36. lovetox

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

  37. lovetox

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

  38. mjk


  39. Zash

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

  40. Zash

    couldn't the send() method fail before?

  41. Zash

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

  42. Zash

    altho stream management could absorb that

  43. mjk

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

  44. lovetox

    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

  45. Zash

    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

  46. mjk

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

  47. singpolyma

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

  48. moparisthebest

    Exceptions were a mistake :)

  49. Zash

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

  50. Zash

    you could do something like that internally in a client too

  51. MattJ

    XEP-0478 <3

  52. singpolyma

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

  53. Zash

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

  54. Zash

    working name "Path MTU" :)

  55. MattJ

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

  56. moparisthebest

    Yep, very excited about that

  57. singpolyma

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

  58. emus

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

  59. moparisthebest

    Great job as usual emus and team

  60. emus