- Ya
- 23 Agosti 2026, 00:48 UTC
- Mwandishi
- Kamo
- Ahadi ya
- 56595cb
Every photo rendered as a broken image. The URL pointed at MediaService's **************** which I took for a general imaging proxy because it spoke HTTP Range. It is not: it is the CHAT ATTACHMENT proxy. It binds a UUID, resolves a MediaObjImg, and authorises by asking whether the caller is a member of the chat SESSION the attachment was posted in. A frame's media has an int64 id and no session, so every request missed. The other candidate was no better. /api/docs/imaging/download buffers the whole file and answers Content-Disposition: attachment with no Range support — fine for a document, wrong for a video, which needs 206 responses to seek and which some browsers will not play at all without them. So this serves them. Authorisation is the FRAME's, which is stronger than a general imaging check: the frame must be this member's and the media must be in that frame, so naming somebody else's image id here finds nothing. Range is handled properly — clamped to the object rather than trusted, 416 with the real length when unsatisfiable, and streamed through MinIOStorageService.openRange rather than read into memory, so a member's holiday video is not held whole in the pod on its way out. Served inline, and privately cacheable for a day: content is addressed by hash, so a given id never changes bytes.