Re: [Nmh-workers] problem with mhshow after mhfixmsg
Ken wrote: > I ... believe you are correct. I say this is fine to commit. I'm glad it turned out to be a simple fix. A different issue is that, in this case, mhfixmsg didn't need to add the text/plain version of the text/html part because the message already contained one. Here's the original message structure excluding most of the image parts: msg part type/subtype size description 3 multipart/alternative1786K boundary="Apple-Mail-2-23735733" 1 multipart/related1784K type="text/html" boundary="Apple-Mail-3-23735734" 1.1 text/html 11K charset="iso-8859-1" 1.2 image/tiff9350 name="pastedGraphic1.tiff" disposition "inline" filename="pastedGraphic1.tiff" 2 text/plain1168 charset="iso-8859-1" The problem is that the two text parts aren't alternatives of a multipart. I'd say that message structure is presumptuous: it doesn't let the recipient display the images if they can't display the html. Anyway, I was initially thinking that mhfixmsg couldn't deal with this, but it can. It should look at the type of the multipart/related and use that as the type of the alterative. I just committed a fix, nmh's introduction to the world of multipart/related. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] problem with mhshow after mhfixmsg
>i think the fix might be a simple extension of a previous fix i made >(c9794733) in show_multi_internal(). >[...] I ... believe you are correct. I say this is fine to commit. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] problem with mhshow after mhfixmsg
i think the fix might be a simple extension of a previous fix i made
(c9794733) in show_multi_internal().
the crux is that no one should be reporting NOTOK for failure to
display parts that weren't actually requested. failure should be
reserved for parts that we really attempted to display. (i think the
default result value of NOTOK gets in the way of this, by making it
too easy to return NOTOK. changing that default might be a path to
simplification that i haven't looked at.)
your workaround ('mhshow -part 1.1.2 -part 1.3') works because
it prevents the inner level from reporting failure, since something
has been displayed successfully.
if my thinking is correct (and it could certainly use review!), here's
a possible patch. the only substantive change is the last stanza.
(i've also renamed the "any_part_ok" variable to better match its
semantics. it confused me, even though i named it in the first
place).
with this change, my original failure case now works, and "make check"
passes, but i don't know that that says enough.
paul
diff --git a/uip/mhshowsbr.c b/uip/mhshowsbr.c
index b76a588..ee7dc75 100644
--- a/uip/mhshowsbr.c
+++ b/uip/mhshowsbr.c
@@ -569,7 +569,7 @@ show_multi_internal (CT ct, int alternate, int concatsw,
int textonly,
intalternating, nowalternate, result;
struct multipart *m = (struct multipart *) ct->c_ctparams;
struct part *part;
-int any_part_ok;
+int request_matched;
CT p;
alternating = 0;
@@ -586,7 +586,7 @@ show_multi_internal (CT ct, int alternate, int concatsw,
int textonly,
*/
result = alternate ? NOTOK : OK;
-any_part_ok = 0;
+request_matched = 0;
for (part = m->mp_parts; part; part = part->mp_next) {
p = part->mp_part;
@@ -594,7 +594,7 @@ show_multi_internal (CT ct, int alternate, int concatsw,
int textonly,
if (part_ok (p, 1) && type_ok (p, 1)) {
int inneresult;
- any_part_ok = 1;
+ request_matched = 1;
inneresult = show_switch (p, nowalternate, concatsw, textonly,
inlineonly, fmt);
@@ -623,7 +623,7 @@ show_multi_internal (CT ct, int alternate, int concatsw,
int textonly,
}
}
-if (alternating && !part && any_part_ok) {
+if (alternating && !part && request_matched) {
if (!alternate)
content_error (NULL, ct, "don't know how to display any of the
contents");
result = NOTOK;
@@ -631,7 +631,9 @@ show_multi_internal (CT ct, int alternate, int concatsw,
int textonly,
}
out:
-return result;
+/* if no parts matched what was requested, there can't have been
+ * any display errors, so we report OK. */
+return request_matched ? result : OK;
}
=--
paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 40.3 degrees)
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] problem with mhshow after mhfixmsg
>your explanation is great. i'll think about what might fix it, but >if you really think you'll be rewriting, i'm willing to let it slide >if it gets tricky feeling. As a short-term fix ... if you make sure you display one of the contents of the innermost multipart/alternative as well as the part you want, it should work fine (e.g., 'mhshow -part 1.1.2 -part 1.3' works). --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] problem with mhshow after mhfixmsg
ken wrote: > >i'm having a problem with mhshow showing some of the parts > >of a message, but only after the message has been run through > >mhfixmsg. > > > >before i start debugging mhshow (which i'm willing to do, though > >it will take me a while), i want to be sure that the output of > >mhfixmsg is valid MIME. > > Okay, so I took a look at this and I can reproduce it. It's not mhfixmsg's > fault. > > The fault is because of the ... unusual (but valid) structure of this > message, and the logic inside of show_multi_internal(). thankyouthankyou. david did some preliminary investigation, and then punted to me (offline). i was just about to delve in, and having been in there before, i was sure my head would explode somewhere along the way. (such a mess when that happens.) your explanation is great. i'll think about what might fix it, but if you really think you'll be rewriting, i'm willing to let it slide if it gets tricky feeling. paul > > At the top level, this message has a multipart/alternative, and enters > show_multi_internal(). This sets alternating, but not alternate, which > is correct: > > /* > * alternate -> we are a part inside an multipart/alternative > * alternating -> we are a multipart/alternative > */ > > The two sub-parts of the top-level multipart/alternative are a text/plain > and a multipart/related. > > The multipart/related is decended into. It contains a multipart/alternative > and multiple image/jpegs. The sub-parts of THAT multipart/alternative are > a text/plain and text/html. Both of the attempts to view the those > parts fail (because part_ok() returns false for both of them). > > But THAT causes show_multi_internal() to return NOTOK. Why? > Well, alternate is passed down as "true" from the top-level > multipart/alternative type. The default return code for > show_multi_internal() is set to NOTOK if alternate is set. > And when processing the multipart/related, alternate is true (because > we're under the top-level multipart/alternative) but alternating > is false (because multipart/related is not an alternate part itself). > That short-circuits the multipart/related processing and it bails > out at that point; that bubbles up to the top-level alternative part > and you get the resulting error. > > Are you confused? I sure was. > > As for a fix ... crud, I don't know. I am reluctant to mess with that > alternative part processing, as it's kind of a mess (I was planning on > rototilling it for the next release). > > --Ken > > ___ > Nmh-workers mailing list > Nmh-workers@nongnu.org > https://lists.nongnu.org/mailman/listinfo/nmh-workers =-- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 40.6 degrees) ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] problem with mhshow after mhfixmsg
>i'm having a problem with mhshow showing some of the parts >of a message, but only after the message has been run through >mhfixmsg. > >before i start debugging mhshow (which i'm willing to do, though >it will take me a while), i want to be sure that the output of >mhfixmsg is valid MIME. Okay, so I took a look at this and I can reproduce it. It's not mhfixmsg's fault. The fault is because of the ... unusual (but valid) structure of this message, and the logic inside of show_multi_internal(). At the top level, this message has a multipart/alternative, and enters show_multi_internal(). This sets alternating, but not alternate, which is correct: /* * alternate -> we are a part inside an multipart/alternative * alternating -> we are a multipart/alternative */ The two sub-parts of the top-level multipart/alternative are a text/plain and a multipart/related. The multipart/related is decended into. It contains a multipart/alternative and multiple image/jpegs. The sub-parts of THAT multipart/alternative are a text/plain and text/html. Both of the attempts to view the those parts fail (because part_ok() returns false for both of them). But THAT causes show_multi_internal() to return NOTOK. Why? Well, alternate is passed down as "true" from the top-level multipart/alternative type. The default return code for show_multi_internal() is set to NOTOK if alternate is set. And when processing the multipart/related, alternate is true (because we're under the top-level multipart/alternative) but alternating is false (because multipart/related is not an alternate part itself). That short-circuits the multipart/related processing and it bails out at that point; that bubbles up to the top-level alternative part and you get the resulting error. Are you confused? I sure was. As for a fix ... crud, I don't know. I am reluctant to mess with that alternative part processing, as it's kind of a mess (I was planning on rototilling it for the next release). --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] problem with mhshow after mhfixmsg
i'm having a problem with mhshow showing some of the parts of a message, but only after the message has been run through mhfixmsg. before i start debugging mhshow (which i'm willing to do, though it will take me a while), i want to be sure that the output of mhfixmsg is valid MIME. here is the unprocessed message. "mhshow -part 1.3 3" works fine on this message. you'll notice that there's no text/plain part corresponding to part 1.1's text/html -- that's what mhfixmsg is going to fix: $ mhlist -verbose -disposition 3 msg part type/subtype size description 3 multipart/alternative1786K boundary="Apple-Mail-2-23735733" 1 multipart/related1784K type="text/html" boundary="Apple-Mail-3-23735734" 1.1 text/html 11K charset="iso-8859-1" 1.2 image/tiff9350 name="pastedGraphic1.tiff" disposition "inline" filename="pastedGraphic1.tiff" 1.3 image/jpeg122K name="IMG_0833.jpeg" disposition "inline" filename="IMG_0833.jpeg" 1.4 image/jpeg 94K name="IMG_0834.jpeg" disposition "inline" filename="IMG_0834.jpeg" 1.5 image/jpeg114K name="IMG_0835.jpeg" disposition "inline" filename="IMG_0835.jpeg" 1.6 image/jpeg 98K name="IMG_0826.jpeg" disposition "inline" filename="IMG_0826.jpeg" 1.7 image/jpeg115K name="IMG_0827.jpeg" disposition "inline" filename="IMG_0827.jpeg" 1.8 image/jpeg173K name="IMG_0828.jpeg" disposition "inline" filename="IMG_0828.jpeg" 1.9 image/jpeg167K name="IMG_0829.jpeg" disposition "inline" filename="IMG_0829.jpeg" 1.10 image/jpeg164K name="IMG_0830.jpeg" disposition "inline" filename="IMG_0830.jpeg" 1.11 image/jpeg162K name="IMG_0831.jpeg" disposition "inline" filename="IMG_0831.jpeg" 1.12 image/jpeg 88K name="IMG_0832.jpeg" disposition "inline" filename="IMG_0832.jpeg" 2 text/plain1168 charset="iso-8859-1" here's the processed version. after this conversion, running "mhshow -part 1.1.1", "mhshow -part 1.1.2", or "mhshow -part 2" works fine. running "mhshow -part 1.3" (or any other 1.n part) gives this: mhshow: don't know how to display any of the contents (content multipart/alternative in message 4) $ mhlist -verbose -disposition 3 msg part type/subtype size description 4 multipart/alternative1787K boundary="Apple-Mail-2-23735733" 1 multipart/related1786K type="text/html" boundary="Apple-Mail-3-23735734" 1.1 multipart/alternative 13K boundary="=_nmh-multipart1.1" 1.1.1 text/html 11K charset="iso-8859-1" 1.1.2 text/plain1281 charset="iso-8859-1" 1.2 image/tiff9350 name="pastedGraphic1.tiff" disposition "inline" filename="pastedGraphic1.tiff" 1.3 image/jpeg122K name="IMG_0833.jpeg" disposition "inline" filename="IMG_0833.jpeg" 1.4 image/jpeg 94K name="IMG_0834.jpeg" disposition "inline" filename="IMG_0834.jpeg" 1.5 image/jpeg114K name="IMG_0835.jpeg" disposition "inline" filename="IMG_0835.jpeg" 1.6 image/jpeg 98K name="IMG_0826.jpeg" disposition "inline" filename="IMG_0826.jpeg" 1.7 image/jpeg115K name="IMG_0827.jpeg" disposition "inline" filename="IMG_0827.jpeg" 1.8 image/jpeg173K name="IMG_0828.jpeg" disposition "inline" filename="IMG_0828.jpeg" 1.9 image/jpeg167K name="IMG_0829.jpeg"
