Bug 1121741 - Attachment format detection is often wonky
Summary: Attachment format detection is often wonky
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Bugzilla
Classification: Community
Component: Attachments/Requests
Version: 4.4
Hardware: All
OS: All
medium
medium vote
Target Milestone: 4.4
Assignee: Matt Tyson 🤬
QA Contact: tools-bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-21 18:36 UTC by Adam Williamson
Modified: 2018-12-09 06:29 UTC (History)
6 users (show)

Fixed In Version: 4.4.5024
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-08-27 00:28:22 UTC


Attachments (Terms of Use)

Description Adam Williamson 2014-07-21 18:36:59 UTC
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

Comment 1 Jason McDonald 2014-07-22 02:01:10 UTC
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.

Comment 2 Jason McDonald 2014-07-25 07:15:38 UTC
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

Comment 4 Adam Williamson 2014-07-25 07:24:23 UTC
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.

Comment 5 Matt Tyson 🤬 2014-08-01 06:58:18 UTC
> 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.

Comment 6 Adam Williamson 2014-08-04 22:32:12 UTC
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?

Comment 7 Matt Tyson 🤬 2014-08-04 22:37:42 UTC
(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.

Comment 8 Adam Williamson 2014-08-08 06:08:26 UTC
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.

Comment 13 Simon Green 2014-08-27 00:28:22 UTC
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.

Comment 14 Adam Williamson 2014-09-09 07:00:54 UTC
(clearing needinfo) I'm happy with the status here; I will file any follow-up issues that arise separately.


Note You need to log in before you can comment on or make changes to this bug.