69031 - mime structure problem

Status: RESOLVED WONTFIX

(MailNews Core :: MIME, defect, P3)

Description

[Henrik Gemal]

The attached mail doesnt render anything in the body or give an attachment in 
Mozilla. Netscape shows a attachment.

the mail:
From: [e-mail]
Subject: ****SPECIAL REPORT****
Content-Type: multipart; boundary="_NextPart_0000904A-00000708-03D46548-3049"
Date: Fri, 16 Feb 2001 10:19:22 GMT

--_NextPart_0000904A-00000708-03D46548-3049
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Get a brand new, clean,
--_NextPart_0000904A-00000708-03D46548-3049--

Comment 1

[Henrik Gemal]

Attachment: troubled mime mail

Comment 2

[[e-mail] (gone - use [e-mail] instead)]

Ducarroz, isn't this a DUP of the bug that I filed on you, that has 2 multipart
attachment messages that won't show in the message pane?

Comment 3

[[e-mail] (gone - use [e-mail] instead)]

I am thinking of bug 74649, specifically.

Comment 4

[Jean-Francois Ducarroz]

This is not a dup of bug 74649. Just looks like we don't know what to do with a
message of type "multipart". We should have have "multipart/..."

Comment 5

[Jean-Francois Ducarroz]

Confirmation, if I replace the content type to "multipart/mixed", then the
message body is correclty displayed inline.

Comment 6

[scottputterman]

Jean-Francois, anything we can do about this? 

Comment 7

[Jean-Francois Ducarroz]

probably. We should be able to handle bad multipart type by using by default a
multipart/mixed.

Comment 8

[Denis Antrushin]

RFC<don't recall number> explicitly says that default subtypes are not allowed :-)
But if you're interested, comparison for "multipart/" literal is happen in
mimei.cpp and mimemsg.cpp (as well as in eudora and outlook import code, but
these are not count)
I think that mimei.cpp is relevant here

Comment 9

[Denis Antrushin]

Attachment: treat "multipart" content-type as "multipart/mixed"

Should we do similiar thing for "message" content type?

Comment 10

[scottputterman]

Moving out, but since we have a patch, if it can get reviewed, we can get it in.

Comment 11

[Jean-Francois Ducarroz]

Comment on attachment 63486 [details] [diff] [review]
treat "multipart" content-type as "multipart/mixed"

just after the code you are patching, there is the following code:

      if (!clazz && !exact_match_p)
	/* Treat all unknown multipart subtypes as "multipart/mixed" */
	clazz = (MimeObjectClass *)&mimeMultipartMixedClass;


Looks like we already have the logic to thread unknown/invalid multipart as
multipart/mixed but for some reason this code doesn't seems to work. I would
rather seeing you fixing the existing one that adding new code. Thanks

Comment 12

[Denis Antrushin]

Attachment: patch, v2

Here we go

Comment 13

[Jean-Francois Ducarroz]

Comment on attachment 68307 [details] [diff] [review]
patch, v2

>-    else if (!nsCRT::strncasecmp(content_type,			"multipart/", 10))
>+    else if (!nsCRT::strncasecmp(content_type,			"multipart", 9))
That's good


>-      if      (!nsCRT::strcasecmp(content_type+10,	"alternative"))
>+      if (!content_type[9] || content_type[9] != '/')
>+        ;   // do nothing
>+      else if (!nsCRT::strcasecmp(content_type+10,	"alternative"))
We don't need this part of the fix as we already have a fall through for case
we don't recognize!

do that and I will give you my ok...

Comment 14

[Toni Ballesta]

5 years of bug and...

Comment 15

[Toni Ballesta]

No, 5 years from last message. 12 years! Why don't close this?

Comment 16

[Joshua Cranmer [:jcranmer]]

Good point. No one else has provided any other message which has such an equally malformed MIME type, so there's no reason to fix it.