Failed to handle multipart/alternative message



19 years ago
11 years ago


(Reporter: jefft, Assigned: rhp)


Windows NT

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [rtm-] r=rhp, sr=mscott)


(5 attachments)



19 years ago
Jeff Tsai wrote:
Enclosed is a patch which fixes the problem.

-- Jeff

Jeff Tsai wrote:
I don't think anyone is aware of this problem. Since this is a
multipart/alternative message libmime should always present the text/html
version of the message. This apparently is a bug.

-- Jeff

Sol Goldfarb wrote:
Is anyone aware of the attached problem? Apparently, Netscape 6 is incorrectly
displaying the contents of some messages.

If someone is familiar with this issue, can you please reply to Craig Haft



-------- Original Message --------
Subject: Fwd: problem with NS 6.0 mail
Date: Tue, 7 Nov 2000 16:58:25 EST

Got vacation reply from kmurray which suggested you.

Craig Haft

Sol Goldfarb
Group Product Manager, Netscape Client Product Marketing
Telephone: (650) 937-2931
AIM Screen Name: nscpgold

problem with NS 6.0 mail
Tue, 7 Nov 2000 16:50:25 EST

! I'm the developer/manager for the AOL IMAP server.  Our QA group noticed a
problem in test that looks like a bug in Netscape 6.  If the message being
read looks something like:

  Subject: test
  MIME-Version: 1.0
  Content-Type: multipart/alternative; boundary=1

  Content-Type: text/x-aol; charset=iso-8859-1

  Some plain text
  Content-Type: text/html; charset=iso-8859-1

  Some HTML text

Then NO text is displayed to the user, and not attachment is available.  The
only way for the user to see the text is to view the page source.  We were
expecting the client to ignore the "text/x-aol" piece and only display the
"text/html" part.  If the first part is changed to "text/plain" or
"x-foo/x-aol", then the HTML part IS displayed.  It appears as thought the
problem is caused when Netscapes sees a "text" part with and unrecogized
"x-aol" subtype.  FYI, the text/x-aol type is used by some of the AOL
newletters and is used to contain text that is formatted for our older
(non-HTML capable) clients.  It actually may contain a limited subset of HTML
that the older clients support, so it is not really plain text.

From RFC 2046

4.1.4.  Unrecognized Subtypes

Unrecognized subtypes of "text" should be treated as subtype "plain"as long
as the MIME implementation knows how to handle the charset.Unrecognized
subtypes which also specify an unrecognized charsetshould be treated as
"application/octet- stream".

Craig Haft


Index: mimemalt.cpp
RCS file: /cvsroot/mozilla/mailnews/mime/src/mimemalt.cpp,v
retrieving revision 1.4
diff -u -r1.4 mimemalt.cpp
--- mimemalt.cpp	1999/11/06 03:32:43	1.4
+++ mimemalt.cpp	2000/11/08 06:18:28
@@ -213,7 +213,7 @@
are themselves unknown.

-  MimeObjectClass *clazz = mime_find_class (ct, sub_hdrs, self->options, PR_TRUE);
+  MimeObjectClass *clazz = mime_find_class (ct, sub_hdrs, self->options, PR_FALSE);
PRBool result = (clazz
? clazz->displayable_inline_p(clazz, sub_hdrs)

Comment 1

19 years ago
Created attachment 18938 [details]
example message

Comment 2

19 years ago
Created attachment 18939 [details] [diff] [review]
a fix

Comment 3

19 years ago
thanks Jeff. 

I'll put this on the stack :-)

- rhp
Target Milestone: --- → Future

Comment 4

19 years ago
Marking [rtm need info] to get r=/sr=/testing done.  Please do that and move to
[rtm+] when ready.  I hope there isn't another respin, but I'd like this to be
ready if there is.
Keywords: rtm
Whiteboard: [rtm need info]


19 years ago
Target Milestone: Future → M19

Comment 5

19 years ago
Adding reviewers ....

Comment 6

19 years ago
Let me explain how the fix work. To handle multipart/alternative message we need
to go through all the alternative part to cache the most content rich part that
our client can handle. We are failing on text/x-aol part. We couldn't find a
mime class to handle it due to the strict rule of exact matching the content-typ
when calling mime_find_class(...., PR_TRUE). Since text/x-aol is a generic text/
content type we could simply let it handle by MimeUntypedText class. Passing in
mime_find_class(...., PR_FALSE) does the job correctly and smoothly. It's the
right and correct fix.

Comment 7

19 years ago
Does 4.x have the same problem? From the code, I would expect that it does.

Comment 8

19 years ago
It could be. I don't have the dogbert tree handy to check with.

Comment 9

19 years ago
Can't you just save the sample message to a local folder and read it with 4.x?
I'll try that myself.

Comment 10

19 years ago
4.x did have the same problem, which is reassuring. But Rich should really be 
the reviewer here...

Comment 11

19 years ago
Yes, this looks good. r: rhp

Also, I will be out doing Mozilla evangelism today so if Jeff can spearhead 
this, that would be great.

- rhp

Comment 12

19 years ago
Yes, I'll do that. There is one more thing taht we need to test with. We need to
add more alternative type in the message for example, ftp type.

Comment 13

19 years ago
Did some more test on adding more content-type to it. We still have problems of
handling content types other than "text/". For all "text/" subtypes, we can
handle it correctly. mscott can you give a sr=?

Comment 14

19 years ago
how does passing PR_FALSE change the semantic behavior of mime_find_class? What
does this argument do? thanks!

Comment 15

19 years ago
The boolean variable specifies whether to find a mime class exactly matching the
content-type/subtype we reguested or a mime class which can handle content-type/
in general. For this particular case, if we pass in PR_TRUE then we are
requesting for exact mime class which can handle text/x-aol. Unfortunately, we
don't specific implementing this experimental content-type. However, for general
text content-type we do have a generic text mime class to handle it. Passing in
PR_FALSE still go through the logic of finding an exact matching class. In
addition if we found a mime class which can handle text/ content-type we return
it back to the caller.

Comment 16

19 years ago
ahh cool, so we still look for an exact match first and if we can't find it we
use a general text class.
Thanks for the explanation!


Comment 17

19 years ago
rtm+ ...
Priority: P3 → P1
Whiteboard: [rtm need info] → [rtm+] r=rhp, sr=mscott

Comment 18

19 years ago
I don't believe this bug warrants a respin nor do I think it's an rtm type bug.
Let's catch it in 6.5 and check it into the tip.

Comment 19

19 years ago
Agreed, just trying to make it ready.

Comment 20

19 years ago
This doesn't seem like it would handle the case where a particular alternative
just cannot be handled, but a higher fidelity one has not yet been processed.
Seems like we should validate ALL parts before bailing out shouldn't we?

Comment 21

19 years ago
We are not handle all sorts of alternative types at the moment but we do for all
the "text/" alternative types. That's probably the most general case especially
people using our client. The way multipart/alternative works is the message
starts with the lowest to highest content rich alternative part. We have to
parse all parts and pick one that the mail client can handle.

Comment 22

19 years ago
Created attachment 18963 [details]
example message - 2

Comment 23

19 years ago
Okay, the patch I proposed does fix all the problems. I just had a not well
formatted message to test with. (see new example message for better idea) For
parts we cannot handle we return MimeExternalObjectClass which is equivalent to
content-type "application/octal-stream". This a correct fix for all cases.
Simple and does the right thing.

Comment 24

19 years ago
rtm-, a server solution will be required for this.
Whiteboard: [rtm+] r=rhp, sr=mscott → [rtm-] r=rhp, sr=mscott

Comment 25

19 years ago
Created attachment 18966 [details]
example message - 3

Comment 26

19 years ago
Created attachment 18967 [details]
example message - 3

Comment 27

19 years ago
I don't understand "a server solution will required for this." 

Comment 28

19 years ago
Sorry, I should have said we can't afford to respin for this fix.  The CD3 build 
has been certified and we don't have any time to try again.

Comment 29

19 years ago
I thought you were saying that MTA should provide the solution. Thanks for the

Comment 30

19 years ago
Fix checked in to the trunk only. Mark it as fixed.
Last Resolved: 19 years ago
Resolution: --- → FIXED


19 years ago
QA Contact: esther → pmock

Comment 31

19 years ago
Changing qa assign to


18 years ago
QA Contact: pmock → laurel

Comment 32

18 years ago
OK using apr17 commercial trunk build win98
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.