Images are bridged to IRC as URLs which force a download

[CyberShadow]

Messages with "msgtype": "m.image" are sent to IRC with an URL such as https://matrix.example.com/_matrix/media/r0/download/matrix.org/xxxxxxxxxxxxxxxxxxxxxxxx/image.png. However, Synapse serves these endpoints with Content-Disposition: attachment; filename=image.png. This instructs web browsers to offer to save the image to disk, instead of simply displaying it.

This makes it annoying for IRC users to see images posted by Matrix users.

#227 looks related.

As to how this could be fixed... first, the spec doesn't seem to require any particular Content-Disposition header, nor does it offer any way for clients to request a particular content-disposition. So, Synapse seems to be sending the header on its own volition. Changing this in Synapse might be an option, but another way would be to try to fix this together with #227, which will probably require Heisenbridge to run its own HTTP server. Integrated setups such as https://github.com/spantaleev/matrix-docker-ansible-deploy could simplify setup and configure routes to Heisenbridge's HTTP server without requiring significant effort from users. I see Heisenbridge already uses asynchronous I/O, so maybe throwing in an HTTP server would not be a significant ordeal?

[tulir]

It's a synapse regression matrix-org/synapse#15885, so I'd hope they fix it there

[signaleleven]

Unfortunately the consensus in matrix-org/synapse#15885 seems to be that the bridge should figure out how to serve content independently :(
It's not a tragedy (and there are workarounds in the link above if your homeserver is behind a proxy that can do some header massaging...) but I agree it's unfortunate.

Just to play with the idea, would there be any other benefit in heisenbridge serving content directly? It's really not a common IRC bouncer use case...

[CyberShadow]

There is a Synapse PR to revert it for some basic types:
matrix-org/synapse#15988

Just to play with the idea, would there be any other benefit in heisenbridge serving content directly? It's really not a common IRC bouncer use case...

Well, it will need to do that anyway to support encrypted rooms.

[hifi]

One fairly easy hack is to run a separate reverse proxy just for Heisenbridge and set its MEDIAURL to the public side of that so that any link it hands out will go through the massaging. I don't think it makes much sense for Heisenbridge itself to serve media.

[joecool1029]

Looks like this was resolved, I checked after nginx-proxy was ripped from the ansible playbook and I don't hit it anymore. It may have also been fixed by the referenced synapse bug.

[signaleleven]

I confirm it was fixed before. I also use the ansible playbook, and I have not updated yet (I have traefik in front, but nginx is still behind, so the default config until yesterday).
I don't have the issue.