Closed Bug 238706 Opened 20 years ago Closed 20 years ago

[FIXr]Wrong Content-Type for unknown data (application/x-vnd.mozilla.guess-from-ext)


(Core Graveyard :: File Handling, defect, P1)



(Not tracked)



(Reporter: askwar, Assigned: bzbarsky)


(Keywords: regression)


(2 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040317 Firefox/0.8.0+ (mmoy)
Build Identifier: Mozilla Thunderbird 0.5+ (Windows/20040321)

When bug 220807 was fixed, a new Content-Type for "wrong" text/plain data was
introduced: application/x-vnd.mozilla.guess-from-ext.

MN (or at least my Thunderbird version), also uses this Content-Type when a is
attached, for which the OS (in my case, the Windows XP registry) doesn't know a

Reproducible: Always
Steps to Reproduce:
1. Make sure that the OS doesn't know a Content-Type for the to be attached file
type. For Windows XP, open regedit and go to HKEY_CLASSES_ROOT\.ext and make
sure that there is NO string called "Content Type".
2. Compose a message.
3. Attach a file.
4. Send message.
5. Receive message.
6. Have a look at the Content Type of the attached file.
Actual Results:  
The attached file has:
Content-Type: application/x-vnd.mozilla.guess-from-ext;

Expected Results:  
I'd expect either:

Content-Type: application/octet-stream;
Content-Type: text/plain;

Since each and every attachment is sent with Content-Disposition: inline;, I'd
like application/octet-stream best, since this allows every receiving user of
"every" MUA to save the attached file. But Content-Disposition type issue is
some other bug, I suppose. 

This is a regression of Bug 220807, I suppose. In Thunderbird 0.5 (release), the
issue wasn't present.

I'm attaching a .eml file with the wrong content-type for the attached file.
Adding regression keyword.
Keywords: regression
This file contains a saved email message. The email message has an attachment,
whose Content-Type is application/x-vnd.mozilla.guess-from-ext.
This bug is also present in the currently nightly of „The Suite“:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040325
Marking NEW.
Ever confirmed: true
Comment on attachment 145003 [details] [diff] [review]
This should fix it

The idea is that nsUnknownDecoder proper should never produce this type, since
that converter is used in various places to detect types in general, even for
loads not destined for the URILoader
Attachment #145003 - Flags: superreview?(darin)
Attachment #145003 - Flags: review?(cbiesinger)
Assignee: sspitzer → file-handling
Component: MIME → File Handling
Product: MailNews → Browser
QA Contact: stephend → ian
Priority: -- → P1
Summary: Wrong Content-Type for unknown data (application/x-vnd.mozilla.guess-from-ext) → [FIX]Wrong Content-Type for unknown data (application/x-vnd.mozilla.guess-from-ext)
Target Milestone: --- → mozilla1.7final
Comment on attachment 145003 [details] [diff] [review]
This should fix it

hm, yeah, this'll work
Attachment #145003 - Flags: review?(cbiesinger) → review+
Attachment #145003 - Flags: superreview?(darin) → superreview+
Comment on attachment 145003 [details] [diff] [review]
This should fix it

Could this please be approved for 1.7?	This fixes the content sniffer to not
produce bogus internal types unless it's being used in bogus internal ways....
Attachment #145003 - Flags: approval1.7?
Summary: [FIX]Wrong Content-Type for unknown data (application/x-vnd.mozilla.guess-from-ext) → [FIXr]Wrong Content-Type for unknown data (application/x-vnd.mozilla.guess-from-ext)
Comment on attachment 145003 [details] [diff] [review]
This should fix it

a=chofmann for 1.7
Attachment #145003 - Flags: approval1.7? → approval1.7+
Fixed for 1.7.
Assignee: file-handling → bzbarsky
Closed: 20 years ago
Resolution: --- → FIXED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.