-
Bug
-
Resolution: Timed out
-
Medium
-
None
-
2.5.2, 2.6.0, 4.1
-
1
-
Severity 2 - Major
-
Trying to display an image file that doesn't have an image extension but has the mime type set correctly to an image type results in the following error:
Unable to embed resource: attachment of type application/octet-stream
Confluence should respect the mime type and display the attachment as an image. This situation can arise relatively easily by using the chart macro's attachment support which allows the attachment name to be anything. See http://confluence.atlassian.com/display/~jnolen/Test. T
- relates to
-
-
- Closed
-
-
CONFSERVER-6119 Default !embed! rendering to <img> if we can't determine the mime type
- Closed
[CONFSERVER-9733] Mime type ignored for image attachments
Thank you for taking the time to raise, comment or vote on this Bug. We regret to inform you that due to a limited number of reports and based on our current backlog of higher impact issues that we are closing this issue as Timed Out.
If this issue is still impacting you on a recent version please feel free to comment with the affected version. Any further details you may be able to provide regarding reproduction or impact of this issue may help us better address this issue.
Thanks again.
Regards,
Confluence Development
Jamie Echlin
added a comment - dmason - I think that only applies to newly created images, not to ones created with previous versions of Mockups. However they're not responding to my questions through their support channel so not sure.
Anyway, I have worked round this with apache mod_rewrite, to rewrite the bad image mime type to a good one.
Jamie Echlin
added a comment - dmason - I think that only applies to newly created images, not to ones created with previous versions of Mockups. However they're not responding to my questions through their support channel so not sure.
Anyway, I have worked round this with apache mod_rewrite, to rewrite the bad image mime type to a good one. jechlincs it looks like Balsamiq Mockups have fixed the MIME type used by their saved images since version 2.2.2 of Balsamiq Mockups for Confluence.
Jamie Echlin
added a comment - Has this been inadvertently or otherwise fixed recently?
In Confluence 4.3.1 it seems to respect the mime-type provided for the attachment. Which is great, but also bad because it breaks Balsamiq Mockups in confluence 4.3.1, which creates images but with bogus mime-types such as application/png and img/png (not image/png). Most browsers correctly detect the PNG image, but IE8 does not, and just shows them as a broken image.
Jamie Echlin
added a comment - Has this been inadvertently or otherwise fixed recently?
In Confluence 4.3.1 it seems to respect the mime-type provided for the attachment. Which is great, but also bad because it breaks Balsamiq Mockups in confluence 4.3.1, which creates images but with bogus mime-types such as application/png and img/png (not image/png). Most browsers correctly detect the PNG image, but IE8 does not, and just shows them as a broken image. Reopenning this issue as it is still applicable to the current confluence.
Should be re-opened.
While I agree old items should be cleaned up, shouldn't some effort be expended to determine if the bug is still a problem in the current release?
BTW, in 4.1, the problem shows differently. An image with an extension displays inline while an image without an extension shows as a link (not recognized as an image).
Bob Swift
added a comment - - edited Should be re-opened.
While I agree old items should be cleaned up, shouldn't some effort be expended to determine if the bug is still a problem in the current release?
BTW, in 4.1, the problem shows differently. An image with an extension displays inline while an image without an extension shows as a link (not recognized as an image). I am cleaning up issues reported against very old versions of Confluence with no activity in the last 4 years.
If the issue is still applicable to the latest version, please comment and I will re-open it.
Timed Out is certainly not the right closing code. Won't Fix is more appropriate with your explanation. It is a well defined and repeatable bug that you are choosing not to fix.