[Catalyst] Re: Encoding problem - ?fastcgi?

Ash Berlin ash_cpan at firemirror.com
Mon Oct 8 19:37:14 GMT 2007

I'm also sending generated PDFs from my FastCGI bassed app. The only
difference between my setup and yours appears to be the use of

"Works fine for me." Not very useful I'm affraid.


Richard Robinson wrote:
> On Mon, Oct 08, 2007 at 02:07:18PM +0200, A. Pagaltzis wrote:
>> Hi Richard,
>> did you ever get this sorted? Quoting in full since you seem to
>> have been warnocked. I have no idea what to suggest but am
>> curious about this issue as a matter of personal interest.
> Nice word, I hadn't met it before. Exactly - is no-one else doing this, or
> is everyone else doing it with no problem ?
> No, I haven't got any further, I'm kind of stuck on it. The workaround makes
> it go away for now & there are other things I need to be sorting out too, so
> I'm just kind of waiting for an idea to appear from somewhere ... 
>> * Richard Robinson <catalyst at beulah.qualmograph.org.uk> [2007-09-20 20:15]:
>>> I got my all-singing all-dancing Catalyst app onto a proper
>>> server a few days ago. It's all going much better than I
>>> thought it might, a couple of friendly guinea-pigs, a fine crop
>>> of helpful comments, glitches getting spotted & fixed, a
>>> thriving TODO list ... and one problem which worries me - I
>>> prefer bugs to be in my code, because then I can fix them and
>>> end of story, but I don't think this is.
>>> There is a point where I send data out as a variety of other
>>> mime-types. This is either text, in a small range of iso-8859
>>> encodings (I work in utf8 internally, "of course", so this is
>>> encoded specifically). or binary, generated from that text as a
>>> temporary file by external programs and read in from that. This
>>> is output with, eg,
>>> $c->res->content_type('application/pdf');
>>> $c->res->body($data);
>>> Developing & testing this on my machine at home, this works as
>>> it should. On the remote server, I can view the files directly,
>>> and they're as they should be; I can request the data through
>>> :3000 from script/appname_server.pl, and again, it's correct;
>>> but hand it out through script/appname_fastcgi.pl +
>>> mod_fastcgi/apache and it's broken; each single byte with the
>>> high bit set is replaced by a "0xC3 0xsomethingelse" pair -
>>> it's been recoded into utf8, with values that assume it was
>>> Latin 1 to start with (regardless of anything I put in the
>>> Content-Type). Workaround is to replace the code above with a
>>> redirect to the temporary file, which then goes out through
>>> Static::Simple and arrives uncorrupted.
>>> The data leaves my code with the utf8 flag unset, and is
>>> handled properly by C::P::Unicode. So I think it must be in the
>>> fastcgi conversation ? Has anybody else seen this, or have any
>>> ideas ?  I can't see any changes in C::E::FastCGI.pm that offer
>>> any Clue, and I'm really not sure where to go next.
>>> System at home, where it doesn't happen, is Apache/2.0.54 with
>>> Catalyst modules from, I think, last January or thereabout (the
>>> new Debian stable caught me by suprise, bringing the home box
>>> up to date is going to be a big job & I have other things I'd
>>> rather be doing).  Remote system, where it does happen, is
>>> Apache/2.2.3 with cpan upgrade a few days ago. mod_fastcgi is
>>> the same on both (2.4.2)
>> Regards,
>> -- 
>> Aristotle Pagaltzis // <http://plasmasturm.org/>
>> _______________________________________________
>> List: Catalyst at lists.scsys.co.uk
>> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
>> Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
>> Dev site: http://dev.catalyst.perl.org/

More information about the Catalyst mailing list