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

Status: RESOLVED FIXED

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

Description

[Alexander Skwar]

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
Content-Type.

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;
or:
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.

Comment 1

[Alexander Skwar]

Adding regression keyword.

Comment 2

[Alexander Skwar]

Attachment: Email message w/ attachment of wrong Content-Type

This file contains a saved email message. The email message has an attachment,
whose Content-Type is application/x-vnd.mozilla.guess-from-ext.

Comment 3

[Alexander Skwar]

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

Comment 4

[Alex Bishop]

Marking NEW.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Attachment: This should fix it

Comment 6

[Boris Zbarsky [:bzbarsky]]

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

Comment 7

[Boris Zbarsky [:bzbarsky]]

Taking.

Comment 8

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 145003 [details] [diff] [review]
This should fix it

hm, yeah, this'll work

Comment 9

[Boris Zbarsky [:bzbarsky]]

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....

Comment 10

[chris hofmann]

Comment on attachment 145003 [details] [diff] [review]
This should fix it

a=chofmann for 1.7

Comment 11

[Boris Zbarsky [:bzbarsky]]

Fixed for 1.7.