JPEG Images have .jpe extension - this can cause issues

[mtippmann]

If .jpe is missing in the list of web-server mime types and x-content-type-options: nosniff headers are set pictures are not shown but instead downloaded because the mime-type of the picture is application/octet-stream.

nginx (at least 1.14.0) lacks .jpe in the mime.types files so this should be pretty common. also setting x-content-type-options: nosniff is considered best practice for security so this might affect quite a few instances.

I've found a related pull-request: #3404

Fixing this might improve the out of box experience for a lot of installations.

thanks to @chpietsch@chaos.social for bringing it up:
https://social.bau-ha.us/@mt/100186932802506001

---

Mastodon 2.4.1 / nginx 1.14

• I searched or browsed the repo’s other issues to ensure this is not a duplicate.
• This bug happens on a tagged release and not on master (If you're a user, don't worry about this).

[Gargron]

I suppose we should just hardcode a special fix for jpeg?

[Gargron]

I suppose we should just hardcode a special fix for jpeg?

[mtippmann]

I'm not familiar with the code-base :( and I'm not sure where the .jpe extension is coming from - in that case it was tweets by moa.party that ended up in .jpe - normal posts does seem to have the correct extension. Maybe adding a note to the deployment notes would be enough until the core issue can be tackled?

[mtippmann]

I'm not familiar with the code-base :( and I'm not sure where the .jpe extension is coming from - in that case it was tweets by moa.party that ended up in .jpe - normal posts does seem to have the correct extension. Maybe adding a note to the deployment notes would be enough until the core issue can be tackled?

[ThibG]

I believe the .jpe comes from the original filename and is preserved on upload (please tell me if I'm wrong). Which I don't really think is an incorrect behavior, but it can lead to the issue reported here.
I think this comes from 7db7d68, which changed the logic a bit regarding filename extensions.
I do not believe preserving the filename extension (if it matches the content-type) is wrong, but I'm not sure it has any merit either. I guess we should either revert to Paperclip's thingy or maybe unconditionally use the first (most common? I don't know if the mime/types package guarantees such a thing) returned extension?

[ThibG]

I believe the .jpe comes from the original filename and is preserved on upload (please tell me if I'm wrong). Which I don't really think is an incorrect behavior, but it can lead to the issue reported here.
I think this comes from 7db7d68, which changed the logic a bit regarding filename extensions.
I do not believe preserving the filename extension (if it matches the content-type) is wrong, but I'm not sure it has any merit either. I guess we should either revert to Paperclip's thingy or maybe unconditionally use the first (most common? I don't know if the mime/types package guarantees such a thing) returned extension?

[Dryusdan]

So, I have a quick fix for this issue. Not in Mastodon but on reverse proxy (nginx for me), it's bad, it's ugly but it's work.
In file /etc/nginx/conf/mime.types or /etc/nginx/mime.types, on line image/jpeg we see this to values : jpeg jpg;, add jpe and restart nginx

It's work :)

[Dryusdan]

So, I have a quick fix for this issue. Not in Mastodon but on reverse proxy (nginx for me), it's bad, it's ugly but it's work.
In file /etc/nginx/conf/mime.types or /etc/nginx/mime.types, on line image/jpeg we see this to values : jpeg jpg;, add jpe and restart nginx

It's work :)