Bug 1121741

Summary:	Attachment format detection is often wonky
Product:	[Community] Bugzilla	Reporter:	Adam Williamson <awilliam>
Component:	Attachments/Requests	Assignee:	Matt Tyson 🤬 <mtyson>
Status:	CLOSED CURRENTRELEASE	QA Contact:	tools-bugs <tools-bugs>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	4.4	CC:	awilliam, bugzilla, jmcdonal, mtyson, rjoost, szhou
Target Milestone:	4.4
Target Release:	---
Hardware:	All
OS:	All
Whiteboard:
Fixed In Version:	4.4.5024	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-08-27 00:28:22 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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.