Wrong detection of multipart

RT Developers
1

Hello.
According to MIME-Tools documentation, citation:
"As a special case, |message/| is currently ambiguous: depending on the
parser, a |message/| might be treated as a singlepart, with a
MIME::Body and no parts. Use bodyhandle() as the final arbiter."
But in Attachment_Overlay.pm RT uses parts() call and then die on
->bodyhandle()->as_string() call.
Attached patch fix it.
Good luck. Ruslan.

rt3.bad_multipart_detection.patch (427 Bytes)

2 
   Hello.

According to MIME-Tools documentation, citation:
“As a special case, |message/| is currently ambiguous: depending on the
parser, a |message/| might be treated as a singlepart, with a
MIME::Body and no parts. Use bodyhandle() as the final arbiter.”
But in Attachment_Overlay.pm RT uses parts() call and then die on
->bodyhandle()->as_string() call.

This patch looks incredibly suspect to me. Do you have an example
testcase that shows how the current behavior is flawed that we can add
to the test suite?

Attached patch fix it.
Good luck. Ruslan.

— rt3_b/lib/RT/Attachment_Overlay.pm 2003-07-31 12:14:40.000000000 +0400
+++ rt3/lib/RT/Attachment_Overlay.pm 2003-08-25 19:42:21.000000000 +0400
@@ -133,7 +133,7 @@
=~ /^.\bfilename="(.)"$/ ? $1 : ‘’
};

  • if ( $Attachment->parts ) {
  • if (not defined $Attachment->bodyhandle ) {
    $id = $self->SUPER::Create(
    TransactionId => $args{‘TransactionId’},
    Parent => 0,

Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.