Closed
Bug 59619
Opened 24 years ago
Closed 8 years ago
MIME types should not be case sensitive
Categories
(Core Graveyard :: Tracking, defect)
Core Graveyard
Tracking
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
People
(Reporter: ewv, Assigned: chofmann)
References
(Depends on 1 open bug, Blocks 1 open bug)
Details
Attachments
(2 files)
(deleted),
text/html
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review |
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•24 years ago
|
||
Confirming on build 2000110906 - Linux/Mandrake 7.2. According to rfc 1521 types
and subtypes of a content-type are case insensitive.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•24 years ago
|
QA Contact: sairuh → shrir
Comment 2•24 years ago
|
||
Since Don has left, Vishy is taking his bugs in bulk, pending reassignment.
thanks,
Vishy
Assignee: don → vishy
nav triage team:
We should fix this. Marking nsbeta1, mozilla0.9, reassigning to pchen
Would like to fix this, but won't get to this for mozilla0.9. Marking nsbeta1-,
resetting target milestone
Marking nsbeta1+, mozilla0.9.1
Comment 6•24 years ago
|
||
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
nav triage team:
Pushing out to mozilla0.9.3
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Comment 8•24 years ago
|
||
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.
Updated•24 years ago
|
Whiteboard: (py8ieh: make sure this fixes bug 78106)
Comment 10•23 years ago
|
||
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•23 years ago
|
||
Comment 12•23 years ago
|
||
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
Comment 13•23 years ago
|
||
Boris,
Aren't you deep in the guts of this code right now?
Cheers,
James
Comment 14•23 years ago
|
||
Comment 15•23 years ago
|
||
sr=jst
Comment 16•23 years ago
|
||
*** Bug 86614 has been marked as a duplicate of this bug. ***
r=heikki.
It seems like the XML and XUL content sinks are already doing the right thing.
a=roc on behalf of drivers
Comment 19•23 years ago
|
||
Checked in attachment 39113 [details] [diff] [review]. Does this bug needs to stay open for other issues?
Comment 20•23 years ago
|
||
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?
Blocks: 57423
Comment 21•23 years ago
|
||
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 ...
Updated•23 years ago
|
Status: NEW → ASSIGNED
Comment 22•23 years ago
|
||
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•23 years ago
|
||
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
Status: ASSIGNED → NEW
Comment 24•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
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
Comment 27•23 years ago
|
||
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•23 years ago
|
||
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 word@irc.mozilla.org <nick>?
of these, 12467 should all work.
mass changes, cc favorites. ok, i'm going to play w/ this before i sleep
Comment 29•23 years ago
|
||
*** Bug 96169 has been marked as a duplicate of this bug. ***
Comment 30•23 years ago
|
||
FWIW, the test cases on both this bug and bug 96169 work for me on Linux 2001082016
Updated•23 years ago
|
Component: XP Apps → File Handling
QA Contact: shrir → sairuh
Comment 31•23 years ago
|
||
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•23 years ago
|
||
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)
Target Milestone: mozilla1.0 → mozilla1.0.1
Comment 33•23 years ago
|
||
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
Comment 34•23 years ago
|
||
my butterfingers; this is why I wasn't going to do all those code changes!
Assignee: timeless → sairuh
Comment 35•23 years ago
|
||
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
Comment 36•23 years ago
|
||
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... :-/
Updated•22 years ago
|
QA Contact: sairuh → petersen
Comment 37•22 years ago
|
||
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•22 years ago
|
||
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'.
Updated•22 years ago
|
Blocks: input-helper-apps
Comment 39•22 years ago
|
||
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.
Priority: P3 → P2
Comment 40•22 years ago
|
||
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
Comment 41•22 years ago
|
||
I almost forgot to mention that Boris Z. suggested that this should be a tracking bug.
Comment 43•21 years ago
|
||
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 → ---
Comment 44•20 years ago
|
||
(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•20 years ago
|
||
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•20 years ago
|
||
> 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•18 years ago
|
||
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•18 years ago
|
||
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•8 years ago
|
||
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.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → INCOMPLETE
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•