[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
C::P::Unicode.

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

-ash

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