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 [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]