[Catalyst] Re: Encoding problem - ?fastcgi?

[Richard Robinson]

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/

-- 
Richard Robinson
"The whole plan hinged upon the natural curiosity of potatoes" - S. Lem