Created attachment 272257 [details] Testing whether automatic detection is to blame, with a simple ASCII text file. As in for instance bug #365671, the attachment initially showed up as text/x-log, which is rather silly when it's plain text/plain and nothing else, other than that it has a .log filename extension. I'll attach some files hoping to find out whether this is user-induced or triggered by the auto-detect feature.
Oh, so it wasn't that? So perhaps it's set like that by an erring user who thinks that text/x-log actually means something...
A search finds both new and old bugs with attachments with this MIME type. https://bugs.gentoo.org/buglist.cgi?list_id=133309&field0-0-0=attachments.mimetype&query_format=advanced&type0-0-0=substring&value0-0-0=x-log
(In reply to comment #1) > Oh, so it wasn't that? So perhaps it's set like that by an erring user who > thinks that text/x-log actually means something... I can't reproduce it, is what I meant.
https://bugs.gentoo.org/show_activity.cgi?id=365999
https://bugs.gentoo.org/show_activity.cgi?id=366095
https://bugs.gentoo.org/show_activity.cgi?id=366073
Since it's usually text/x-log I am seeing, I am pretty sure now that this is an "auto-detected" MIME type, which happens to be entirely identical to the text/plain MIME type all web browsers are already aware of. If it is the auto-detection feature that is performing so badly, then we might as well turn it off until it is fixed.
https://bugs.gentoo.org/show_activity.cgi?id=366383
Here it was a shell script instead of the usual log "file type": https://bugs.gentoo.org/show_activity.cgi?id=366503
https://bugs.gentoo.org/show_activity.cgi?id=367597 No idea what text/x-mpsub might be.
The TypeSniffer extension (which should do a proper auto-detection on the server side in case the browser sets it to 'application/octet-stream') has been disabled for now. Auto-detect is still enabled but only on the client side, so most auto-detect attachments will have 'application/octet-stream'.
IIRC that's more or less exactly the behaviour that we used to have, and this should mean a lot less correction work. Let's see how it goes.
Well, that also means that a lot of log files, build.log etc. are 'application/octet-stream' due to failed detection through the browser.
*** Bug 367983 has been marked as a duplicate of this bug. ***
I have no idea how this browser detection is supposed to work, but couldn't we default to text/plain in the manual case? Most attachments are text/plain.
(In reply to comment #15) > I have no idea how this browser detection is supposed to work, but couldn't we > default to text/plain in the manual case? Most attachments are text/plain. Most attachments are definitely not application/octet-stream, or maybe every single one should be, but with text/plain we would be more specific, if sometimes wrong. This is a simple workaround for the real problem of lousy file type detection that we could implement today.
The default is text/plain now, for the moment.
It seems to be working out. Maybe we can close this bug now.
Attachments: The encoding of text files can be automatically detected when uploading them as attachments. This has been improved in Bugzilla 4.2. It would be cool if you or others could test the improved auto-detect so we may consider to make it the default again.
Note for myself: Bugzilla 4.4 When a user uploads a new attachment and lets the "Content Type" field set to "auto-detect", Bugzilla now does its own MIME type detection if the web browser tells him that the attachment is of type "application/octet-stream", in an attempt to make a better guess than the web browser. In all other cases, Bugzilla still trusts what the browser tells him.
*** Bug 408049 has been marked as a duplicate of this bug. ***
Please test.
