59470 - Failed to handle multipart/alternative message

Status: VERIFIED FIXED

(MailNews Core :: MIME, defect, P1)

Description

[jefft]

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
([e-mail]).

Thanks,

Sol

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


Got vacation reply from kmurray which suggested you.

Craig Haft

-- 
Sol Goldfarb
Group Product Manager, Netscape Client Product Marketing
Telephone: [phone]
AIM Screen Name: nscpgold


Subject:
problem with NS 6.0 mail
From:
[e-mail]
Date:
Tue, 7 Nov 2000 16:50:25 EST
To:
[e-mail]

! 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:

  To: [e-mail]
  From: [e-mail]
  Subject: test
  MIME-Version: 1.0
  Content-Type: multipart/alternative; boundary=1

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

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

  Some HTML text
  --1--

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
attachment.htm
Content-Type:
text/html
Content-Encoding:
7bit

nsmail-5.eml
Content-Type:
message/rfc822
Content-Encoding:
7bit






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)
: PR_FALSE);
bugalt.txt
Content-Type:
text/plain
Content-Encoding:
7bit

Comment 1

[jefft]

Attachment: example message

Comment 2

[jefft]

Attachment: a fix

Comment 3

[rhp (gone)]

thanks Jeff. 

I'll put this on the stack :-)

- rhp

Comment 4

[selmer (gone)]

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.

Comment 5

[jefft]

Adding reviewers ....

Comment 6

[jefft]

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

[David :Bienvenu]

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

Comment 8

[jefft]

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

Comment 9

[David :Bienvenu]

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

[David :Bienvenu]

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

Comment 11

[rhp (gone)]

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

[jefft]

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

[jefft]

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

[Scott MacGregor]

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

Comment 15

[jefft]

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

[Scott MacGregor]

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!
sr=mscott

Comment 17

[jefft]

rtm+ ...

Comment 18

[Scott MacGregor]

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

[jefft]

Agreed, just trying to make it ready.

Comment 20

[selmer (gone)]

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

[jefft]

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

[jefft]

Attachment: example message - 2

Comment 23

[jefft]

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

[selmer (gone)]

rtm-, a server solution will be required for this.

Comment 25

[jefft]

Attachment: example message - 3

Comment 26

[jefft]

Attachment: example message - 3

Comment 27

[jefft]

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

Comment 28

[selmer (gone)]

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

[jefft]

I thought you were saying that MTA should provide the solution. Thanks for the
clarification.

Comment 30

[jefft]

Fix checked in to the trunk only. Mark it as fixed.

Comment 31

[pmock]

Changing qa assign to [e-mail]

Comment 32

[laurel]

OK using apr17 commercial trunk build win98