funny multipart/related not displaying correctly

funny multipart/related not displaying correctly

[Dan Christensen]

[-- Attachment #1: Type: text/plain, Size: 1153 bytes --]

The message attached below isn't displayed well by Gnus.  I suspect
that it is incorrect MIME.  Unfortunately, I'm getting a lot of
messages like this from a certain source who can't change the software
which generates them.  So I'm wondering:  are they in fact incorrect
MIME, and is there a way to get Gnus to detect this and display them
properly automatically?

The messages consist of a multipart/related with
type="multipart/alternative" and two sub-parts.  The first subpart
(part 1) is a multipart/alternative (which is correct) and the second
(part 2) is an image (replaced below by a text/plain part).  The
enclosing multipart/related shouldn't be an alternative; I want to see
one of the first two parts and the last part.  If I hit `K m', Gnus
somehow can tell this is what I want and fixes the message.  I'd like
this to happen automatically.

By the way, before being fixed, `K b' only shows one button, which
corresponds to part 1, the alternative.  But I never see part 2.  
`C-u K b' fixes this, but shouldn't I see an alternative to part 1
with `K b'?

`C-d' on the message shows the correct heirarchy of parts.

Here is the message:


[-- Attachment #2: bad message --]
[-- Type: text/plain, Size: 763 bytes --]

>From nobody Wed Feb 21 00:19:30 2001
X-From-Line: test@test Tue Feb 20 16:41:01 2001
Message-Id: <200102202140.f1KLe4p32575@zwolle.execulink.net>
From: test@test
Date: Tue, 20 Feb 2001 16:12:11
MIME-Version: 1.0
Content-Type: multipart/related;
        type="multipart/alternative";
        boundary="----=unique-boundary-1"

This is a multi-part message in MIME format.

------=unique-boundary-1
Content-Type: multipart/alternative;
        boundary="----=unique-boundary-2"


------=unique-boundary-2
Content-Type: text/plain;

text/plain alternative 1a

------=unique-boundary-2
Content-Type: text/plain;

text/plain alternative 1b

------=unique-boundary-2--

------=unique-boundary-1
Content-Type: text/plain

text/plain part 2

------=unique-boundary-1--


[-- Attachment #3: Type: text/plain, Size: 66 bytes --]


Thanks for any suggestions,

Dan

-- 
Dan Christensen
jdc@uwo.ca

Re: funny multipart/related not displaying correctly

[ShengHuo ZHU]

Dan Christensen <jdc@uwo.ca> writes:

> The message attached below isn't displayed well by Gnus.  I suspect
> that it is incorrect MIME.  Unfortunately, I'm getting a lot of
> messages like this from a certain source who can't change the software
> which generates them.  So I'm wondering:  are they in fact incorrect
> MIME, and is there a way to get Gnus to detect this and display them
> properly automatically?
> 
> The messages consist of a multipart/related with
> type="multipart/alternative" and two sub-parts.  The first subpart
> (part 1) is a multipart/alternative (which is correct) and the second
> (part 2) is an image (replaced below by a text/plain part).  The
> enclosing multipart/related shouldn't be an alternative; I want to see
> one of the first two parts and the last part.  If I hit `K m', Gnus
> somehow can tell this is what I want and fixes the message.  I'd like
> this to happen automatically.

> By the way, before being fixed, `K b' only shows one button, which
> corresponds to part 1, the alternative.  But I never see part 2.  
> `C-u K b' fixes this, but shouldn't I see an alternative to part 1
> with `K b'?
> 
> `C-d' on the message shows the correct heirarchy of parts.

gnus-mime-display-multipart-as-mixed is the variable, but maybe you
don't want multipart/alternative displayed as mixed. So, I just added
gnus-mime-display-multipart-related-as-mixed and
gnus-mime-display-multipart-alternative-as-mixed.

ShengHuo

Re: funny multipart/related not displaying correctly

[Dan Christensen]

ShengHuo ZHU <zsh@cs.rochester.edu> writes:

> Dan Christensen <jdc@uwo.ca> writes:
> 
> > The message attached below isn't displayed well by Gnus.  I suspect
> > that it is incorrect MIME.  Unfortunately, I'm getting a lot of
> > messages like this from a certain source who can't change the software
> > which generates them.  So I'm wondering:  are they in fact incorrect
> > MIME, and is there a way to get Gnus to detect this and display them
> > properly automatically?
> > 
> > The messages consist of a multipart/related with
> > type="multipart/alternative" and two sub-parts.  The first subpart
> > (part 1) is a multipart/alternative (which is correct) and the second
> > (part 2) is an image (replaced below by a text/plain part).  The
> > enclosing multipart/related shouldn't be an alternative; I want to see
> > one of the first two parts and the last part.  If I hit `K m', Gnus
> > somehow can tell this is what I want and fixes the message.  I'd like
> > this to happen automatically.
> 
> > By the way, before being fixed, `K b' only shows one button, which
> > corresponds to part 1, the alternative.  But I never see part 2.  
> > `C-u K b' fixes this, but shouldn't I see an alternative to part 1
> > with `K b'?
> > 
> > `C-d' on the message shows the correct heirarchy of parts.
> 
> gnus-mime-display-multipart-as-mixed is the variable, but maybe you
> don't want multipart/alternative displayed as mixed. So, I just added
> gnus-mime-display-multipart-related-as-mixed and
> gnus-mime-display-multipart-alternative-as-mixed.

Thanks, that helps a lot.  Is there a way I can set variables like
this (and mm-discouraged-alternatives and mm-inline-override-types) on
a per user basis?  For example, can they be functions which examine
the headers of the current article and decide how to display it?  Most
of the time I discourage html, but in this case I need to see it.

...

I've just looked at rfc2112 on multipart/related, and now I think that
the original message might be legitimate.  The
"type=multipart/alternative" in the headers actually specifies the
type of the first part, which is correct.  So now I don't see why
`K b' doesn't show me the last part.  In the actual message, rather
than the modified one I included yesterday, the last part is referenced
in the second html part, but w3 doesn't inline the image for some
reason.  (I'm using emacs 21 pretest which does correctly inline
the image after `C-u K b' or with
gnus-mime-display-multipart-related-as-mixed set to t.)
Gnus complains that there is an html error

  Error while rendering html; showing as text/plain

but with w3-debug-error set to t, there is no *HTML Debug* buffer
and w3-display-errors says:

  w3-display-errors: No HTML errors on this page!  Amazing, isn't it?

If anyone is curious about this, the original message is located
at 

  http://jdc.math.uwo.ca/bad-message

in mbox format (34k).

Thanks,

Dan

-- 
Dan Christensen
jdc@uwo.ca

Re: funny multipart/related not displaying correctly

[ShengHuo ZHU]

Dan Christensen <jdc@uwo.ca> writes:

[...]

> Thanks, that helps a lot.  Is there a way I can set variables like
> this (and mm-discouraged-alternatives and mm-inline-override-types) on
> a per user basis?  For example, can they be functions which examine
> the headers of the current article and decide how to display it?  Most
> of the time I discourage html, but in this case I need to see it.

I think there is no such built-in function.

> I've just looked at rfc2112 on multipart/related, and now I think that
> the original message might be legitimate.  The
> "type=multipart/alternative" in the headers actually specifies the
> type of the first part, which is correct.  So now I don't see why
> `K b' doesn't show me the last part. 

The handle is not displayed, so `K b' has no effect.

> In the actual message, rather than the modified one I included
> yesterday, the last part is referenced in the second html part, but
> w3 doesn't inline the image for some reason.  (I'm using emacs 21
> pretest which does correctly inline the image after `C-u K b' or
> with gnus-mime-display-multipart-related-as-mixed set to t.)  Gnus
> complains that there is an html error
> 
>   Error while rendering html; showing as text/plain
> 
> but with w3-debug-error set to t, there is no *HTML Debug* buffer
> and w3-display-errors says:
> 
>   w3-display-errors: No HTML errors on this page!  Amazing, isn't it?
> 
> If anyone is curious about this, the original message is located
> at 
> 
>   http://jdc.math.uwo.ca/bad-message
> 
> in mbox format (34k).

This often happens in Emacs 21, not other ones. W3 throws the error
but doesn't give info.

ShengHuo