[Maypole] Unicode, CGI::Untaint, Class::DBI::FromCGI

[Gaal Yahas]

On Wed, May 05, 2004 at 08:46:35PM +0100, Tony Bowden wrote:
> On Wed, May 05, 2004 at 10:16:24PM +0300, Gaal Yahas wrote:
> > This is another one of those general questions about a problem that
> > isn't Maypole's fault. I realize this, but it's not clear what module
> > does handle this, so just a pointer would be appreciated: is either of
> > the modules mentioned in the subject responsible? What should be done
> > to fix this?
> 
> If I'm understanding the problem (and of course it's quite possible that
> I'm not), I would say that it's something that should be handled 
> closer to the Maypole end of the flow. I'm open to persuasion that it's
> something that Class::DBI::FromCGI should take care of, but I'm hesitant
> to move it into CGI::Untaint.
> 
> I have no strong arguments to back any of this up at this point,
> however, so I'll certainly consider all opinions!

Okay, it was indeed "closer to the Maypole end of the flow": it turned
out that my browser was treating the page as ISO-8859-1 (Latin-1);
*despite* the http-equiv directive in custom/header that specifies
utf-8. I traced this to Apache's "AddDefaultCharset On" directive,
enabled by default and defualting to latin-1[1]. Perversely, my HTTP
responses contained *two* Content-Type lines and evidently my browser
was honoring the wrong one.

So:

1. I changed AddDefaultCharset from "On" to "utf-8"; this fixed the
   symptom.

2. It's not clear to me why the http-equiv doesn't override Apache's
   defualt (which by rights should only be added to pages that don't
   specify their encoding explicitly).

Perhaps this is some mod_perl misconfiguration on my part? Or a bug in
mod_perl or apache? I'm using a non-DSO mod_perl with a recent apache.

[1] due to security reasons; see http://www.apache.org/info/css-security/

-- 
Gaal Yahas <gaal@forum2.org>
http://gaal.livejournal.com/