[rt-devel] RT 4.2.7: application/octet-stream
bmcnally at uw.edu
Wed Oct 1 18:49:22 EDT 2014
I'm wondering if we can get some additional help with this. I'm not sure
I'll be able to track down the bug in a timely manner.
For my own clarification, my reading of the error indicates that the
MakeMIMEEntity() -> SetMIMEEntityToUTF8() -> SetMIMEEntityToEncoding()
Where SetMIMEEntityToEncoding() fails saying it got the wrong input
(characters vs. a byte string). So, does that mean that a step was
skipped, where the text should have been converted to a byte string but
wasn't? Or does it mean that it was a bytestring at one time but somehow
got converted back to characters? If it helps at all, I found that if I
used the email interface, and passed my message though mimedefang, I did
not have this problem (text would render as expected in the web interface).
Is there anything I can provide about my environment that might be useful?
On 09/26/2014 01:57 PM, Alex Vandiver wrote:
> On 09/26/2014 04:10 PM, Brian McNally wrote:
>> I'm running version 1.66 of DBIx::SearchBuilder.
> I'm running out of thoughts as to what's different about your
> environment that would cause this breakage. Your debugging steps should
> roughly be:
> All MIME::Entity bodies in RT should now, as of 4.2.7, be bytes and not
> characters. For the comment/correspond codepath, this is enforced by
> RT::Interface::WebMakeMIMEEntity --  called from . Check that the
> input to  is characters, and that the output from
> ->bodyhandle->as_string contains the UTF-8 encoding of those characters
> -- i.e. no codepoints above 255, and the "UTF-8" flag should be off.
> You will need to rack down where the UTF-8 flag of
> ->bodyhandle->as_string starts being on -- that is where your bug lies.
> The Devel::Peek module will likely be useful in your investigation. If
> you have cusomizations or extensions, start by disabling them and see if
> that improves matters.
> - Alex
More information about the rt-devel