59619 - MIME types should not be case sensitive

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Tracking, defect)

Description

[Eric Vaandering (no email)]

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

Comment 1

[Arjen Hommersom]

Confirming on build 2000110906 - Linux/Mandrake 7.2. According to rfc 1521 types
and subtypes of a content-type are case insensitive.

Comment 2

[Viswanath Ramachandran]

Since Don has left, Vishy is taking his bugs in bulk, pending reassignment.
thanks,
	Vishy

Comment 3

[Paul Chen]

nav triage team:

We should fix this. Marking nsbeta1, mozilla0.9, reassigning to pchen

Comment 4

[Paul Chen]

Would like to fix this, but won't get to this for mozilla0.9. Marking nsbeta1-,
resetting target milestone

Comment 5

[Paul Chen]

Marking nsbeta1+, mozilla0.9.1

Comment 6

[Viswanath Ramachandran]

as discussed in team meeting, moving all Nav+ team members nsbeta1+ P3 bugs from 
mozilla0.9.1 to mozilla0.9.2. 

Comment 7

[Paul Chen]

nav triage team:

Pushing out to mozilla0.9.3

Comment 8

[Aleksey Nogin]

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.

Comment 9

[Anatoly Kochergin]

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

Comment 10

[Bob Clary [:bc] (inactive)]

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.

Comment 11

[Bob Clary [:bc] (inactive)]

Attachment: example of inline CSS with type text/CSS

Comment 12

[Paul Chen]

nav triage team:

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

Comment 13

[James Salsman]

Boris,

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

Cheers,
James

Comment 14

[Peter Van der Beken [:peterv]]

Attachment: Fix for <style type="text/CSS">

Comment 15

[Johnny Stenback (:jst)]

sr=jst

Comment 16

[Chase Tingley]

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

Comment 17

[Heikki Toivonen (remove -bugzilla when emailing directly)]

r=heikki.

It seems like the XML and XUL content sinks are already doing the right thing.

Comment 18

[Robert O'Callahan (:roc) (email my personal email if necessary)]

a=roc on behalf of drivers

Comment 19

[Peter Van der Beken [:peterv]]

Checked in attachment 39113 [details] [diff] [review]. Does this bug needs to stay open for other issues?

Comment 20

[James Salsman]

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 

  s/mimeType.Equals/mimeType.EqualsIgnoreCase/g

but that might not catch all of them.

And certainly this is possible by 0.9.3; is it not?

Comment 21

[timeless]

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

Comment 22

[James Salsman]

Some cases selected from:
  http://lxr.mozilla.org/seamonkey/search?string=mimeType 

/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], 
aMimeType)))

/modules/plugin/nglsrc/nsPluginHostImpl.cpp, line 3806 -- if(nsnull == 
PL_strcasecmp(tag->mMimeTypeArray[i],
"audio/x-pn-realaudio-plugin"))
/modules/plugin/nglsrc/nsPluginHostImpl.cpp, line 3809 -- if(nsnull == 
PL_strcasecmp(tag->mMimeTypeArray[i],
"application/pdf"))
/modules/plugin/nglsrc/nsPluginHostImpl.cpp, line 3812 -- if(nsnull == 
PL_strcasecmp(tag->mMimeTypeArray[i],
"application/x-shockwave-flash"))
/modules/plugin/nglsrc/nsPluginHostImpl.cpp, line 3815 -- if(nsnull ==
PL_strcasecmp(tag->mMimeTypeArray[i],"application/x-director"))
/modules/plugin/nglsrc/nsPluginHostImpl.cpp, line 3819 -- if(nsnull ==
PL_strcasecmp(tag->mMimeTypeArray[i],"image/x-quicktime"))
/modules/plugin/nglsrc/nsPluginHostImpl.cpp, line 3822 -- if(nsnull ==
PL_strcasecmp(tag->mMimeTypeArray[i],"image/x-macpaint"))
/modules/plugin/nglsrc/nsPluginHostImpl.cpp, line 3825 -- if(nsnull ==
PL_strcasecmp(tag->mMimeTypeArray[i],"video/quicktime"))

/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, 
type))

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

/plugin/oji/MRJ/plugin/Source/MRJPlugin.cpp, line 236 -- if 
(::strcmp(aPluginMIMEType,
"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
(aName.Equals(NS_ConvertASCIItoUCS2(mPluginTag.mMimeTypeArray[index])))

/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() ||
mimeType.Equals(NS_LITERAL_STRING("text/css")))

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.

Comment 23

[James Salsman]

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.

Comment 24

[Peter Van der Beken [:peterv]]

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() ||
mimeType.Equals(NS_LITERAL_STRING("text/css")))

Comment 25

[James Salsman]

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

Cheers,
James

Comment 26

[timeless]

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.

Comment 27

[James Salsman]

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* 
inEditorShell)
 101              
//------------------------------------------------------------------------------
--------------------------------------
 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?

Comment 28

[timeless]

sfraser is easy, here's a bad algorithm
1 <emailaddress from blame>
2 <nick>@netscape.com
3 <nick>@mozilla.org
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 [e-mail] <nick>?

of these, 12467 should all work.

mass changes, cc favorites. ok, i'm going to play w/ this before i sleep

Comment 29

[Christopher Aillon (sabbatical, not receiving bugmail)]

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

Comment 30

[Christopher Aillon (sabbatical, not receiving bugmail)]

FWIW, the test cases on both this bug and bug 96169 work for me on Linux 2001082016

Comment 31

[benc]

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?

Comment 32

[Asa Dotzler [:asa]]

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 
moved)

Comment 33

[James Salsman]

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.

Comment 34

[James Salsman]

my butterfingers; this is why I wasn't going to do all those code changes!

Comment 35

[sairuh (rarely reading bugmail)]

back to default owner, as i'm already down as the QA contact here. ;)  bill,
feel free to triage this as needed!

Comment 36

[sairuh (rarely reading bugmail)]

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

Comment 37

[Brendan Lynch]

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.

Comment 38

[Francois Gouget]

This also impacts plugins. In particular it prevents the BMWFilms site from
working because they tag their stream as 'video/QuickTime' instead of
'video/quicktime':

http://intl.bmwfilms.com/clap.asp?template=deliverystream&country=eurorussia&film=tickertrailer

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

Comment 39

[James Salsman]

Memorializing some pertinent documentation, the result of bug 61408:
http://bugzilla.mozilla.org/attachment.cgi?id=112432&action=view

Bumping priority on the theory that "code cleanlyness is next to 
user friendlyness.

Comment 40

[James Salsman]

Boris got the parts of this bug I care about.  Against my better judgement, I'm puting the 
priority back a notch.

Comment 41

[James Salsman]

I almost forgot to mention that Boris Z. suggested that this should be a tracking bug.

Comment 42

[Vedran Miletic]

retargeting

Comment 43

[Boris Zbarsky [:bzbarsky]]

To tracking.  If someone finds a case where this is a problem, please do file a
bug blocking this one, and cc me.

Comment 44

[Charles Dorner]

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

Comment 45

[James Salsman]

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:?
http://lxr.mozilla.org/seamonkey/search?string=message%2Frfc822

Comment 46

[Boris Zbarsky [:bzbarsky]]

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

Comment 47

[Danai Sae-Han]

This old (and nasty ;) bug is still present in Moz TB (Mozilla-Thunderbird 1.5.0.10).

More specifically, when I send an encrypted email from Mew (Messaging in the Emacs World; http://www.mew.org/) 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 (http://mozdev.org/bugs/show_bug.cgi?id=7269), but the author can't fix it elegantly since this is a TB issue.

I hope this bug can be fixed soon.

Thanks


/Danai

Comment 48

[Boris Zbarsky [:bzbarsky]]

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.

Comment 50

[BMO Automation]

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.