[Catalyst] Re: Encoding problem - ?fastcgi?

Octavian Rasnita orasnita at gmail.com
Mon Oct 8 19:43:34 GMT 2007


I also had a maybe similar problem. I've used XML::Simple to parse an XML 
file which is UTF-8 encoded and if I used the Catalyst test web server it 
worked fine, but if I wanted to load the application with Apache, the page 
was double encoded.

I used:
$obj = XMLin($content) if $content =~ /\w/;
$c->stash->{b1price} = $obj->{B1Price}->{content} || "";

So I needed to get each value of the $obj reference and encode it to UTF-8 
before sending it to the browser in order to make it work under Apache also.

Octavian

----- Original Message ----- 
From: "Andreas Marienborg" <omega at palle.net>
To: "The elegant MVC web framework" <catalyst at lists.scsys.co.uk>
Sent: Monday, October 08, 2007 8:08 PM
Subject: Re: [Catalyst] Re: Encoding problem - ?fastcgi?


>I had some problems with fastcgi and encoding, specificly stuff getting
> double encoded when I ran it under fastcgi and apache (external fastcgi
> was what I used).
>
> What ended up solving it for me (and breaking it whenever I forgot to
> follow the guideline later) was the following
>
> this failed:
>
> $href = {
> apejens => "some value",
> };
>
> # this worked
> $href = {
> 'apejens' => "some value",
> };
>
> So quoting the keys in all hashes worked for me then, which to seems
> like a rather magical solution, but I figured I might as well share it
> if it somehow helps someone else
>
>
> - andreas
>
> On Mon, 2007-10-08 at 16:50 +0100, 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/
>>
>
>
> _______________________________________________
> 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