Closed Bug 59619 Opened 24 years ago Closed 8 years ago

MIME types should not be case sensitive


(Core Graveyard :: Tracking, defect)

Not set


(Not tracked)



(Reporter: ewv, Assigned: chofmann)


(Depends on 1 open bug, Blocks 1 open bug)



(2 files)

I have a helper application rule set up for application/postscript to run my PS
viewer.  On receiving an attachment with type APPLICATION/POSTSCRIPT my rule was
not used. I had to set up another one to cover this case.

Mime types should probably be converted to lower case before being compared
Confirming on build 2000110906 - Linux/Mandrake 7.2. According to rfc 1521 types
and subtypes of a content-type are case insensitive.
Ever confirmed: true
QA Contact: sairuh → shrir
Since Don has left, Vishy is taking his bugs in bulk, pending reassignment.
Assignee: don → vishy
nav triage team:

We should fix this. Marking nsbeta1, mozilla0.9, reassigning to pchen
Assignee: vishy → pchen
Keywords: nsbeta1
Target Milestone: --- → mozilla0.9
Would like to fix this, but won't get to this for mozilla0.9. Marking nsbeta1-,
resetting target milestone
Keywords: nsbeta1nsbeta1-
Target Milestone: mozilla0.9 → ---
Marking nsbeta1+, mozilla0.9.1
Keywords: nsbeta1-nsbeta1+
Target Milestone: --- → mozilla0.9.1
as discussed in team meeting, moving all Nav+ team members nsbeta1+ P3 bugs from 
mozilla0.9.1 to mozilla0.9.2. 
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Blocks: 78106
nav triage team:

Pushing out to mozilla0.9.3
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Bug #83611 discusses an alternative approach to this problem - instead of having
case insensitive mime types, conver all mimetypes to lowercase when parsing
Content-type header.
*** Bug 84434 has been marked as a duplicate of this bug. ***
Whiteboard: (py8ieh: make sure this fixes bug 78106)
I do not believe that bug 83611 will fix the entire problem. content types
specified in type attributes in HTML are supposed to be case insensitve.
Manipulating the Content-type in the HTTP header does not address this problem.

If you code a STYLE tag with type="text/CSS" Mozilla does not recognize it as CSS.

I am attaching a simple page with inline CSS with type text/CSS that does not
work in Mozilla 0.9.1/win2k.
nav triage team:

Yes, this sucks, but not a mozilla0.9.3 stopper. Pushing out to mozilla1.0
Target Milestone: mozilla0.9.3 → mozilla1.0

Aren't you deep in the guts of this code right now?

*** Bug 86614 has been marked as a duplicate of this bug. ***

It seems like the XML and XUL content sinks are already doing the right thing.
Checked in attachment 39113 [details] [diff] [review]. Does this bug needs to stay open for other issues?
The status whiteboard says, "(py8ieh: make sure this fixes bug 78106)"
but 78106 is a tracking bug.  Please erase that.  Why does this have 
multiple code reviews and is still in NEW state?

I'm going to mark this one as blocking 57423, too, for what should be 
obvious reasons.

This bug does need to stay open until someone fixes it for all mime types, 
not just one.  The general idea would be to seem to be 


but that might not catch all of them.

And certainly this is possible by 0.9.3; is it not?
Blocks: 57423
james expressed an interest in working on this bug, so i'm giving it to him. 
also clearing status as I agree it doesn't make sense. odder still is that 
hixie doesn't appear to be cc (not a big deal i'm sure he'll still get a 
bugmail).  Yes if all we need to do is a few equalsIgonreCases this should be 
very easy for 0.9.3, -- I'm not sure if that's the case and I'm about to have 
my tree in working order so i'll actually be able to figure this out soon ...
Assignee: pchen → jps
Keywords: mozilla0.9.3
Whiteboard: (py8ieh: make sure this fixes bug 78106)
Some cases selected from: 

/editor/base/nsComposerCommands.cpp, line 104 -- if (nsCRT::strcmp(mimeType, 
"text/html") != 0)

/editor/base/nsEditorShell.cpp, line 466 -- if 
(nsCRT::strcmp(gSupportedTextTypes[i], aMIMEType) == 0)

/editor/ui/composer/content/editor.js, line 114 -- return 
(editorShell.contentsMIMEType == "text/html");

/modules/plugin/nglsrc/nsPluginHostImpl.cpp, line 563 -- PRBool defaultplugin = 
(PL_strcmp(mimetype, "*") == 0);

/modules/plugin/nglsrc/nsPluginHostImpl.cpp, line 582 -- if(PL_strcasecmp(mt, 
mimetype) == 0)

/modules/plugin/nglsrc/nsPluginHostImpl.cpp, line 2832 -- if(!aMimeType || 
PL_strcasecmp(aMimeType, "application/x-java-vm"))

/modules/plugin/nglsrc/nsPluginHostImpl.cpp, line 2917 -- 
(PL_strcasecmp(aMimeType, "application/x-java-vm") != 0 && 

/modules/plugin/nglsrc/nsPluginHostImpl.cpp, line 3378 -- if 
(plugins->mMimeTypeArray[cnt] && (0 == strcmp(plugins->mMimeTypeArray[cnt], 

/modules/plugin/nglsrc/nsPluginHostImpl.cpp, line 3806 -- if(nsnull == 
/modules/plugin/nglsrc/nsPluginHostImpl.cpp, line 3809 -- if(nsnull == 
/modules/plugin/nglsrc/nsPluginHostImpl.cpp, line 3812 -- if(nsnull == 
/modules/plugin/nglsrc/nsPluginHostImpl.cpp, line 3815 -- if(nsnull ==
/modules/plugin/nglsrc/nsPluginHostImpl.cpp, line 3819 -- if(nsnull ==
/modules/plugin/nglsrc/nsPluginHostImpl.cpp, line 3822 -- if(nsnull ==
/modules/plugin/nglsrc/nsPluginHostImpl.cpp, line 3825 -- if(nsnull ==

/modules/plugin/npspy/common/epmanager.cpp, line 141 -- if(0 == 
stricmp(eps->mimetype, mimetype))

/modules/plugin/npspy/common/epmanager.cpp, line 200 -- if(0 == 
stricmp(eps->mimetype, pluginType))

/modules/plugin/npspy/common/plugload.cpp, line 133 -- if(0 == stricmp(mimetype, 

/netwerk/mime/src/nsXMLMIMEDataSource.cpp, line 771 -- if ( !nsCRT::strcmp( 
kMIMEType, tempBuffer ) )

/plugin/oji/MRJ/plugin/Source/MRJPlugin.cpp, line 236 -- if 
"application/x-java-frame") == 0) {

/editor/base/nsEditorShell.cpp, line 1789 -- if 
(!mimeTypeCStr.Equals("text/html") && !saveAsText)

/editor/base/nsEditorShell.cpp, line 5196 -- if ( 
!mContentMIMEType.Equals("text/html") &&
!IsSupportedTextType(mContentMIMEType) )

/modules/plugin/nglsrc/nsPluginHostImpl.cpp, line 3554 -- if

/content/html/document/src/nsHTMLContentSink.cpp, line 5014 -- if 
(mimeType.IsEmpty() ||
mimeType.EqualsIgnoreCase("text/css")) { 

/content/html/document/src/nsHTMLContentSink.cpp, line 5057 -- }//if 
(mimeType.IsEmpty() ||

WARNING: not only does the above list not include all comparisons where the 
type's name doesn't include the string "mimetype", it doesn't even include all 
those that do.
I'm a few days at least from a good tree at this point, so I'm passing 
this back over to timeless, who I hope will pass it back to me if he 
doesn't have a working tree on his compile platform by the weekend.
Thanks; I hope that list makes a good starting point.
Assignee: jps → timeless
Um, these are OK. The first one uses EqualsIgnoreCase, the second is in a
comment, which we could update of course.

/content/html/document/src/nsHTMLContentSink.cpp, line 5014 -- if 
(mimeType.IsEmpty() ||
mimeType.EqualsIgnoreCase("text/css")) { 

/content/html/document/src/nsHTMLContentSink.cpp, line 5057 -- }//if 
(mimeType.IsEmpty() ||
What is the most efficient way to assign this or a split-up bug to all those who 
have 'blame' for the code sections above?

Timeless, if you give this back to me, please, I will work on something like 

i'm going to probably nuke my tree, right now i have a working 092 branch but 
it's someone else's so i should be developing on it.
Assignee: timeless → jps
I'm having trouble working on this.  In the first example, the line number
has incremented in blame already:

sfraser 1.24 
  99              PRBool
 100              nsBaseComposerCommand::EditingHTML(nsIEditorShell* 
 102              {
 103                nsXPIDLCString  mimeType;
 104                inEditorShell->GetContentsMIMEType(getter_Copies(mimeType));
 105                if (nsCRT::strcmp(mimeType, "text/html") != 0)

So, given that "sfraser" is to "blame" a number of questions arise:

What is sfraser's email id for bugzilla?  How would I find out?

Is he or she still working on this code?  If not, who gets the bug?

Can someone more familiar with splitting bugs take this from me please?
Theoretically this is almost completely easy, and it distributes well, 
or it would if I knew how to distribute it.  In any case, I haven't had 
the time this month to sit down and open 40 new bugs, even if I could 
figure out out all the coders' email addresses.

Someone with vast tree-write capabilities could probably do this all in 
a fell swoop.  Any takers, please?
sfraser is easy, here's a bad algorithm
1 <emailaddress from blame>
2 <nick>
3 <nick>
4 search bugzilla for bugs assigned to <nick>
5 search bugzilla for bugs qa by <nick>
6 search bugzilla for bugs reported by <nick>
7 /msg <nick>?

of these, 12467 should all work.

mass changes, cc favorites. ok, i'm going to play w/ this before i sleep
*** Bug 96169 has been marked as a duplicate of this bug. ***
FWIW, the test cases on both this bug and bug 96169 work for me on Linux 2001082016
Component: XP Apps → File Handling
QA Contact: shrir → sairuh
re Bob's comment about http:
I think the problem you are refering to was fixed in bug 83611. Is this why we
got some WFM updates at the bottom of this bug?
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
Target Milestone: mozilla1.0 → mozilla1.0.1
Depends on: 114462
Reassigning to Saruh:  this is actually a QA review task, from which many other
bugs may spring (see timeless's comments above.)  These bugs would be insidious
and easy for detractors to use to claim inadequacy if not corrected.  If the
task seems daunting at first, I offer to share it in the following manner:  you
do 1, I do 2, you do 3, etc.  Of course it would be more efficient if done all
at once, but it would also be more reliable if a bona-fide QA person helped.
Assignee: jps → timeless
my butterfingers; this is why I wasn't going to do all those code changes!
Assignee: timeless → sairuh
back to default owner, as i'm already down as the QA contact here. ;)  bill,
feel free to triage this as needed!
Assignee: sairuh → law
whups, sorry if i sounded a bit abrupt there... i'm cc'ing benc on this, who
might be able help out QA-wise for this...except he's currently on sabbatical,
iirc... :-/
QA Contact: sairuh → petersen
I've got another example of this bug, occurring in 1.2beta build on Solaris.  An
Email with an attachment of type 'APPLICATION/pdf' (generated by an old CDE
mailer) will not display with the acrobat plugin; or indeed any Content-type
other than 'application/pdf'.  The Content-type also needs to be forced to
lower-case before being used for plugin checking.
This also impacts plugins. In particular it prevents the BMWFilms site from
working because they tag their stream as 'video/QuickTime' instead of

What is most weird is that this works in Mozilla 1.1 on Windows 'Mozilla/5.0
(Windows; U; WinNT4.0; en-US; rv:1.1) Gecko/20020826', but not in Mozilla 1.1 on
Linux (don't have the agent string handy) or Mozilla 1.2beta on Linux
'Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021016'.
Memorializing some pertinent documentation, the result of bug 61408:

Bumping priority on the theory that "code cleanlyness is next to 
user friendlyness.
Priority: P3 → P2
Boris got the parts of this bug I care about.  Against my better judgement, I'm puting the 
priority back a notch.
Priority: P2 → P3
I almost forgot to mention that Boris Z. suggested that this should be a tracking bug.
Target Milestone: mozilla1.0.1 → Future
To tracking.  If someone finds a case where this is a problem, please do file a
bug blocking this one, and cc me.
Assignee: law → chofmann
Component: File Handling → Tracking
OS: Linux → All
Priority: P3 → --
QA Contact: petersen → chofmann
Hardware: PC → All
Target Milestone: Future → ---
(In reply to comment #43)
> To tracking.  If someone finds a case where this is a problem, please do file a
> bug blocking this one, and cc me.

Also, if an embedded message is sent with Content-Type: MESSAGE/RFC822, the
embedded message is unopenable.
Boris, do you want to open one against the mail reader for that?  I would, but I
have no confirmation that the lowercase "message/rfc822" type does work,
although I assume it would (or is the .eml extention key?)

Which one of these is the culprit, or does this even find it:?
> Boris, do you want to open one against the mail reader for that?

If it's a bug in the mail reader, yes.  The comment was pretty unclear about
what the problem was...

> Which one of these is the culprit, or does this even find it:?

No idea.  I sorta avoid mailnews code.
This old (and nasty ;) bug is still present in Moz TB (Mozilla-Thunderbird

More specifically, when I send an encrypted email from Mew (Messaging in the Emacs World; to a TB account, TB+Enigmail can't read the email and only shows to parts of the email: the first contains the Mime version number, the second the actual encrypted text.

Reason is that Mew sends out the email with "Multipart/Encrypted", while TB only recognizes "multipart/encrypted".  I did the test, and when I manually edit outoing emails from Mew and use only lowercase characters, the email can be opened by TB+Enigmail.

A bug report has already been sent to Enigmail (, but the author can't fix it elegantly since this is a TB issue.

I hope this bug can be fixed soon.


Comment 47 is not this bug.  Please file a separate bug on it, with a clear description of what the problem is (e.g. the enigmail bug talks about a "protocol name", which is clearly not relevant here; the bug would need information about exactly what enigmail is doing, etc).

This bug is a tracking bug for issues related to casing of MIME types; it will not be "fixed" because it only exists to track real fixable issues.
Depends on: 880306
Depends on: 206659
No longer depends on: 880306
Depends on: 880306
Marking all tracking bugs which haven't been updated since 2014 as INCOMPLETE.
If this bug is still relevant, please reopen it and move it into a bugzilla component related to the work
being tracked. The Core: Tracking component will no longer be used.
Closed: 8 years ago
Resolution: --- → INCOMPLETE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.