Feature #19131
closedUse a better content type for attachments created with application/octet-stream
0%
Description
Some email clients will always send attachments with a mime-type of application/octet-stream
instead of correctly setting the attachment of the mime-type. We are aware of Outlook 15 showing this behaviour, but it might not be the only one.
This is a problem in the case where the front-end web server behind which Redmine runs sends the X-Content-Type-Options: nosniff
header, which stops the browser from trying to guess the mime type of files the server sends it (this header is set on the Planio platform for security reasons).
- Redmine blindly trusts the mime-type set by the email client source:/branches/2.6-stable/app/models/mail_handler.rb#L276
- This mime-type gets stored to the DB
- And is served back as the Content-Type of the corresponding thumbnail source:/branches/2.6-stable/app/controllers/attachments_controller.rb#L63
- The browser tries to fetch the thumbnail but gets a file with the Content-Type set to
application/octet-stream
, which isn't considered an image and a broken link/broken image is shown.
Files
Updated by Felix Schäfer over 9 years ago
- File 19131.patch 19131.patch added
The attached patch tries to better guess the mime type of attachments incoming via email if the mime-type of the attachment is set to application/octet-stream
.
If this is an acceptable solution, I would also add a migration to try to find a better mime type than application/octet-stream
for existing attachments with that content type.
Updated by Jean-Philippe Lang over 9 years ago
Any reason to do this in the mail handler and not in the Attachment model? If an image is uploaded via a browser or the API with an incorrect content type, thumbnails and inline images might be broken as well.
Updated by Felix Schäfer over 9 years ago
We have only observed this for emails, but this can be moved to the model without problem too. I will adapt the patch in consequence.
Updated by Jean-Philippe Lang over 9 years ago
Or maybe just store the provided content type and guess a better one when a serving a file, just like it's already done when an attachment have a blank content type. No need for a migration each time we change the guess rule.
Updated by Jean-Philippe Lang over 9 years ago
Index: app/controllers/attachments_controller.rb
===================================================================
--- app/controllers/attachments_controller.rb (revision 13994)
+++ app/controllers/attachments_controller.rb (working copy)
@@ -183,7 +183,7 @@
def detect_content_type(attachment)
content_type = attachment.content_type
- if content_type.blank?
+ if content_type.blank? || content_type == "application/octet-stream"
content_type = Redmine::MimeType.of(attachment.filename)
end
content_type.to_s
Updated by Felix Schäfer over 9 years ago
This is in fact exactly what we have done for Planio until we had worked out a solution here. I had thought the create-time guessing better as this would have to be done only once for each attachment, but that works well too and avoids additional migrations.
Updated by Toshi MARUYAMA over 9 years ago
OpenProject (GPL3) uses another approach of attachment detection.
https://github.com/opf/openproject/commit/fb096b0c86eec9bf49612ef6c8768000c3099841
Updated by Jean-Philippe Lang over 9 years ago
Toshi MARUYAMA wrote:
OpenProject (GPL3) uses another approach of attachment detection.
Sounds a bit overkill to me.
Updated by Jean-Philippe Lang over 9 years ago
- Tracker changed from Defect to Feature
- Subject changed from Don't trust MUAs to always set the correct mime-type for attachments to Use a better content type for attachments created with application/octet-stream
- Status changed from New to Resolved
- Assignee set to Jean-Philippe Lang
- Target version set to 3.0.0
- Resolution set to Fixed
Change committed in r14034.
Updated by Jean-Philippe Lang over 9 years ago
- Status changed from Resolved to Closed