This one has been the case for years, but somehow never got around to filing an issue on it. Our BZ's auto-detection of attachment formats doesn't seem to give the best results. In particular, it often seems to give plain text (usually logs) some kind of type like 'text/x-log' or even 'application/binary'. This is frustrating because then you can't just view the attachment by clicking, it wants to open it in an app. I think most BZ users (reporters, triagers and devs) want any attachment that is just text to be of type 'text/plain'. The most common other types of attachment I think are PNG and JPG images, maybe screen capture videos, and compressed files of various kinds. If those types could all be gotten right and anything that looks at all like text got given 'text/plain' I think people would be happier. In particular, if BZ is reading file extensions and applying 'special' types when it sees something.log , I think it'd be better if it just did text/plain in that case. Ref: https://lists.fedoraproject.org/pipermail/test/2014-July/122081.html most recently, but all Fedora QA folks are more familiar than we'd like to be with the 'edit attachment MIME type' workflow :P
I've noticed this a few times too. I'd be a bit surprised if Red Hat Bugzilla is deviating from the upstream implementation of that feature, but I'll dig into the code and try to make some recommendations for improving it.
After further investigation, I've concluded that Bugzilla is guessing the mime types of each attachment based on the file extension rather than the content. I reached this conclusion after submitting the same icon file six times with different filename extensions to a test instance of Bugzilla. Here's what it did: favicon.ico image/vnd.microsoft.icon favicon.diff patch favicon.jpg image/jpeg favicon.log text/x-log favicon.txt text/plain favicon application/octet-stream
thanks for the testing! obviously content based detection would be the best, but a quick bodge that'd help a lot of cases would simply be to make the type for the .log extension be text/plain not text/x-log . i think that's the one that causes the most heartache.
> I reached this conclusion after submitting the same icon file six times with > different filename extensions to a test instance of Bugzilla. Bugzilla only performs auto detection of the mime type if the uploaded file has a content type of application/octet-stream. If the browser uploads a file with supplied content type of text/x-log then bugzilla won't perform any mime type auto detection. We'll try widening the scope of what we auto detect. This seems to file most text looking files under text/plain.
do you know what causes the supplied content type to be text/x-log? is it something Firefox does when submitting a file with the extension .log, perhaps?
(In reply to Adam Williamson (Red Hat) from comment #6) > do you know what causes the supplied content type to be text/x-log? is it > something Firefox does when submitting a file with the extension .log, > perhaps? Yes, the browser is supping the mime type when the file is uploaded.
awesome, thanks very much! so this change will wind up in the staging BZ, right? I'll try and remember to test it out there.
This change is now live. If there are any issues, do not reopen this bug. Instead, you should create a new bug and reference this bug.
(clearing needinfo) I'm happy with the status here; I will file any follow-up issues that arise separately.