jdev - 2022-09-29

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? ✏

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

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

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

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

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

How large is your stanza?

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)

Oh, no

Block size

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

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

4096 is not the stanza size

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

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 :/

It's a stanza size problem

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

Exactly

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.

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

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

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

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

Like a worst case compressible picture

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

Ok worst case is uncompressed 😄

But nobody has uncompressed pictures

Like the input is always already compressed ✏

Size to resolution is probably linear?

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