Closed Bug 184971 Opened 18 years ago Closed 18 years ago

display MIME type of the server in download dialog and not the mime-type returned by windows registry


(Core Graveyard :: File Handling, defect)

Windows 2000
Not set


(Not tracked)



(Reporter: hauser, Assigned: law)




see description in above bug
-> file handling
Assignee: dougt → law
Component: Networking → File Handling
QA Contact: benc → petersen
Um... We _DO_ show the server-provided type in the download dialog.  We have
specific code to do so, and have for years -- see

So the question is, what's really going on here.  Is there a URL I can hit to
actually see what the server is sending?  What is the server expected to be sending?
No, the problem is that the windows registry maps the server's download MIME 
content type to a file name extension, which in turn gets mapped to another
MIME content type.  The dialog shows the content type to which the file name 
extension is mapped, not the content type that was originally presented by the 
server.  This is all explained in and in the attachment

The server downloaded MIME type application/pkix-cert.  On Win2k, that
maps to file name extension .cer, which maps to MIME type 
application/x-x509-CA-cert.  As shown in the attachment cited above, the 
mozilla dialog shows application/x-x509-CA-cert, but it should show 

The problem with showing the wrong MIME type is that it confounds any 
attempt to diagnose misbehavior.  mozilla recognizes and deals with the 
MIME type application/x-x509-CA-cert when the server provides that type.
But when the server provides a type unknown to mozilla, the user gets the
dialog cited in the attachment above.  So, when the dialog states that the
MIME type was one that mozilla recognizes, it leaves everyone wondering
why in the heck did mozilla show this dialog?  The reader of the dialog
is not able to diagnose the real problem, which is that the server used
a MIME type that mozilla does not recognize.

The URL with which this was originally seen was

I don't know if that URL still acts as before or not, but even if it does
not, this bug is valid and needs to be fixed.
Ok, I finally hunted this down.  This is a Windows-specific bug that only pops
up when a type is mapped to an extension but the extension is mapped to a
different type (which is why it never came up before).

The code mentioned in comment 2 would not cover this case.
This will be fixed, basically, once bug 178122 is resolved.  For the record, the
issue is that GetFromMIMEType on Windows sets the wrong MIME type in the
MIMEInfo (!) and the main helper app service code does not expect such idiocy.
Depends on: 178122
Hmmm, with build 2003021308, I no longer get the anomality on 1)

URLs to hit:                                       MIME-Type:
1)    pkix-cert
2) application/x-x509-ca-cert
3) application/x-x509-email-cert
4) application/x-x509-user-cert

2-4) IMHO still should give the user more control as they do now (next to
nothing) - as reported (,,
Fixed by bug 147679

Closed: 18 years ago
Resolution: --- → FIXED
*** Bug 198578 has been marked as a duplicate of this bug. ***
*** Bug 207076 has been marked as a duplicate of this bug. ***
*** Bug 209840 has been marked as a duplicate of this bug. ***
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.