Failed to handle multipart/alternative message

VERIFIED FIXED

Status

MailNews Core
MIME
P1
normal
VERIFIED FIXED
17 years ago
10 years ago

People

(Reporter: jefft, Assigned: rhp (gone))

Tracking

Trunk
x86
Windows NT

Firefox Tracking Flags

(Not tracked)

Details

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

Attachments

(5 attachments)

(Reporter)

Description

17 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
(clhaft@aol.com).

Thanks,

Sol

-------- Original Message --------
Subject: Fwd: problem with NS 6.0 mail
Date: Tue, 7 Nov 2000 16:58:25 EST
From: CLHaft@aol.com
To: sol@netscape.com


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


Subject:
problem with NS 6.0 mail
From:
CLHaft@aol.com
Date:
Tue, 7 Nov 2000 16:50:25 EST
To:
kmurray@netscape.com

! 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: clhaft@aol.com
  From: tsqa@aol.com
  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
(Reporter)

Comment 1

17 years ago
Created attachment 18938 [details]
example message
(Reporter)

Comment 2

17 years ago
Created attachment 18939 [details] [diff] [review]
a fix
(Assignee)

Comment 3

17 years ago
thanks Jeff. 

I'll put this on the stack :-)

- rhp
Status: NEW → ASSIGNED
Target Milestone: --- → Future

Comment 4

17 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]
(Assignee)

Updated

17 years ago
Target Milestone: Future → M19
(Reporter)

Comment 5

17 years ago
Adding reviewers ....
(Reporter)

Comment 6

17 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

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

Comment 8

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

Comment 9

17 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

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

Comment 11

17 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
(Reporter)

Comment 12

17 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.
(Reporter)

Comment 13

17 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

17 years ago
how does passing PR_FALSE change the semantic behavior of mime_find_class? What
does this argument do? thanks!
(Reporter)

Comment 15

17 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

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

(Reporter)

Comment 17

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

Comment 18

17 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.
(Reporter)

Comment 19

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

Comment 20

17 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?
(Reporter)

Comment 21

17 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.
(Reporter)

Comment 22

17 years ago
Created attachment 18963 [details]
example message - 2
(Reporter)

Comment 23

17 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

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

Comment 25

17 years ago
Created attachment 18966 [details]
example message - 3
(Reporter)

Comment 26

17 years ago
Created attachment 18967 [details]
example message - 3
(Reporter)

Comment 27

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

Comment 28

17 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.
(Reporter)

Comment 29

17 years ago
I thought you were saying that MTA should provide the solution. Thanks for the
clarification.
(Reporter)

Comment 30

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

Updated

17 years ago
QA Contact: esther → pmock

Comment 31

17 years ago
Changing qa assign to pmock@netscape.com

Updated

17 years ago
QA Contact: pmock → laurel

Comment 32

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