jdev - 2022-09-29


  1. nicoco

    Hey all! I am getting this in prosody logs while trying to send PEP avatar via my component: mod_component debug Received invalid XML (stanza-too-large) 4096 bytes: "[some-data]" 2022-09-29T10:34:47.892579714Z mod_component info Disconnecting component, <stream:error> is: not-well-formed in here: https://xmpp.org/extensions/xep-0084.html#revision-history-v0.11 it seems there is no size requirements. I can just resize the avatar data but is this really required? I fail to find the relevant reference about this. any pointers?

  2. nicoco

    Hey all! I am getting this in prosody logs while trying to send PEP avatar via my component: mod_component debug Received invalid XML (stanza-too-large) 4096 bytes: "[some-data]" mod_component info Disconnecting component, <stream:error> is: not-well-formed in here: https://xmpp.org/extensions/xep-0084.html#revision-history-v0.11 it seems there is no size requirements. I can just resize the avatar data but is this really required? I fail to find the relevant reference about this. any pointers?

  3. MattJ

    Size limits in XMPP are (loosely) defined in the RFC: https://xmpp.org/rfcs/rfc6120.html#security-dos

  4. MattJ

    Ultimately they are a per-deployment decision, but the RFC gives you at least "10000" (for the whole stanza)

  5. MattJ

    Ultimately they are a per-deployment decision, but the RFC gives you at least "10000 bytes" (for the whole stanza)

  6. MattJ

    Recent Prosody and ejabberd use 256KB on c2s and 512KB on s2s by default

  7. nicoco

    thanks MattJ. So let's introduce an --avatar-size config parameter then, along with a `TODO: cache this` near the resampling operation… ^^

  8. nicoco

    wait wait wait, but where does that "too-large: 4096 bytes" come from then?

  9. MattJ

    How large is your stanza?

  10. nicoco

    I don't know for sure, but > 512KB probably. I was just curious where the 4096 came from? Does it mean it's exactly 4KiB too large? (just want to make sure I really understand where the error is coming from)

  11. MattJ

    Oh, no

  12. Zash

    Block size

  13. MattJ

    The full 512KB is not read from the socket and pushed to the XML parser in one big blob

  14. MattJ

    This debug message is just telling you about the error raised while processing this chunk of XML it is showing you

  15. MattJ

    4096 is not the stanza size

  16. Zash

    It reads from the socket in chunks of configurable size, defauling to 4k iirc. That's then the size it reports that it showed in the log

  17. nicoco

    oh OK, so it's not a stanza size problem, but a base64 encoding problem I guess? I fail to reproduce it now and did not keep the [some-data] content unfortunately :/

  18. MattJ

    It's a stanza size problem

  19. nicoco

    oh ok, got it, prosody just logs the "chunk that made us go beyond the size limit"

  20. MattJ

    Exactly

  21. nicoco

    thanks, let's resample these images then. it's annoying to estimate what the final stanza size will be, but I'll default to 200×200 max, I think it's reasonable. then if someone wants to increase the limit in their server parameters, they can make this max size as huge as they want.

  22. MattJ

    Yeah. I know at least one client that just reduces the scale in a loop until the right size is achieved 🙂

  23. nicoco

    i think if you go for uncompressed PNG you can predict the size, but with compression enabled, I don't think you can avoid a loop if you want to maximise the resolution while fitting the stanza size. setting a low default value seemed more reasonable to me (those precious CPU cycles!), but it does not feel great either

  24. lovetox

    Could you not calculate the max size of any given PNG size?

  25. lovetox

    Like there must exist a number where a 64x64 PNG with a specific compression setting can go above

  26. lovetox

    Like there must exist a number where a 64x64 PNG with a specific compression setting cant go above

  27. lovetox

    Like a worst case compressible picture

  28. nicoco

    well it can't go above the uncompressed version, for sure :)

  29. lovetox

    Ok worst case is uncompressed 😄

  30. lovetox

    But nobody has uncompressed pictures

  31. lovetox

    Like the input is always already compresses

  32. lovetox

    Like the input is always already compressed

  33. lovetox

    Size to resolution is probably linear?

  34. nicoco

    ~linear to (width×height) I guess (variations of the header size are probably negligible).