Well, what does the database say for content-type? Is the content in the
Sorry. And thanks again for all the help!
mysql> select Subject, Filename, ContentType, ContentEncoding, Headers
from Attachments where id=10792\G
X-Mailer: MIME-tools 5.426 (Entity 5.426)
This really does look like our content-type sniffing for HTML probably
wants to look inside the content for an encoding. But there’s a chicken
and egg problem there.
I think you probably want to see if Encode::Guess does the right thing
with your utf-16 html. If so, then it might be a problem in how RT uses
I look forward to further triage.
Hmmm. Just noticed this error:
[Fri Feb 20 18:32:55 2009] [debug]: Converting ‘UTF-16’ to ‘utf-8’ for
text/html - Re Eprize RPC interface failing on DC registration.htm
[Fri Feb 20 18:32:55 2009] [error]: Encoding error:
UTF-16:Unrecognised BOM 78 at
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/Encode.pm line 190.
And just found this in production:
Feb 19 10:39:28 c0sup-rt02 RT: Encoding error: UTF-16:Unrecognised BOM
78 at /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/Encode.pm line
190. Stack: [/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/Encode.pm:190]
[/opt/rt3/share/html/autohandler:311] defaulting to ISO-8859-1 ->
Word putting in an invalid BOM? I upgraded Encode from 2.26 to 2.31
but it had no effect.