Bug#416097: [request-tracker-maintainers] Bug#416097: character set is completely messed up

[Niko Tyni]

tags 416097 confirmed
thanks

On Sat, Mar 24, 2007 at 08:59:07PM +0100, Steinar H. Gunderson wrote:
> Package: request-tracker3.6
> Version: 3.6.1-4
> Severity: grave
> 
> Hi,
> 
> We're running RT via SpeedyCGI from Apache 2, with MySQL as the backend
> database. After upgrade from an older RT 3.2 installation, the character
> set in the web interface got all screwy -- everything was right in the
> database and per e-mail, but in short, any text would be converted from
> UTF-8 to ISO 8859-1 and then output raw to stdout... unless it was
> somehow close to a character that couldn't be converted to ISO 8859-1
> (such as a heart glyph). Note that I'm saying "close"; other text on the
> page would still go through the same odd conversion.

Hi,

this is also #387104. It's specific to SpeedyCGI, so the severity is
inflated (and vorlon already downgraded it to 'important').

> Simply adding
> 
>   binmode STDOUT, ":utf8";
> 
> to the top of mason_handler.scgi fixed the problem immediately.

Unfortunately this is not enough, it results in corrupted attachments.
The attachment data is not internally tagged as utf8 (and even if it
were, outputting arbitrary binary attachments in utf8 would probably
not be the right thing to do.)

I'm still trying to come up with a proper fix. Since things seem to work
with mod_perl2, there should be a way to fix this on the SpeedyCGI side
without touching the other parts of the code. My experiments with 'use
bytes' and various PerlIO hacks have so far been unsuccessful, though.

Looking back, this should have been documented for Etch. Unfortunately
it's too late now.

Meanwhile, the workaround is to use mod_perl2 instead.
-- 
Niko Tyni   ntyni at iki.fi