Return-Path: 
 <modperl-return-57736-apmail-perl-modperl-archive=perl.apache.org@perl.apache.org>
Delivered-To: apmail-perl-modperl-archive@www.apache.org
Received: (qmail 52862 invoked from network); 23 May 2008 12:30:09 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 23 May 2008 12:30:09 -0000
Received: (qmail 55456 invoked by uid 500); 23 May 2008 12:30:06 -0000
Delivered-To: apmail-perl-modperl-archive@perl.apache.org
Received: (qmail 55433 invoked by uid 500); 23 May 2008 12:30:06 -0000
Mailing-List: contact modperl-help@perl.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:modperl-help@perl.apache.org>
list-unsubscribe: <mailto:modperl-unsubscribe@perl.apache.org>
List-Post: <mailto:modperl@perl.apache.org>
List-Id: <modperl.perl.apache.org>
Delivered-To: mailing list modperl@perl.apache.org
Received: (qmail 55422 invoked by uid 99); 23 May 2008 12:30:06 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 23 May 2008 05:30:06 -0700
X-ASF-Spam-Status: No, hits=1.2 required=10.0
	tests=SPF_NEUTRAL
X-Spam-Check-By: apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Received: from [76.96.30.48] (HELO QMTA05.emeryville.ca.mail.comcast.net)
 (76.96.30.48)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 23 May 2008 12:29:10 +0000
Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51])
	by QMTA05.emeryville.ca.mail.comcast.net with comcast
	id UyeP1Z00416AWCUA507200; Fri, 23 May 2008 12:29:30 +0000
Received: from helm.modperlcookbook.net ([76.117.81.167])
	by OMTA06.emeryville.ca.mail.comcast.net with comcast
	id V0VU1Z0033cbzJc8S00000; Fri, 23 May 2008 12:29:30 +0000
X-Authority-Analysis: v=1.0 c=1 a=Y2Nu90C7U8gA:10 a=Y4iPgPjv-LQA:10
 a=Vt2AcnKqAAAA:8 a=NVITkrpnr1ptZvcSJaAA:9 a=1LUxLKAzlklKc5qOUFnwafAQww0A:4
 a=88iI8knYSJUA:10 a=c5zHXd76wwQA:10
Message-ID: <4836B8A8.6050303@modperlcookbook.org>
Date: Fri, 23 May 2008 08:29:28 -0400
From: Geoffrey Young <geoff@modperlcookbook.org>
User-Agent: Thunderbird 2.0.0.9 (X11/20071115)
MIME-Version: 1.0
To: Clinton Gormley <clint@traveljury.com>
CC: modperl <modperl@perl.apache.org>
Subject: Re: Bug: Character sets and $r->custom_response
References: <1211537392.16659.42.camel@getafix.traveljury.com>
In-Reply-To: <1211537392.16659.42.camel@getafix.traveljury.com>
X-Enigmail-Version: 0.95.6
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org



Clinton Gormley wrote:
> Hi all
> 
> There seems to be a bug in the mod_perl2/apache2 handling of character
> sets for $r->custom_response().  I'm not sure which is at fault.
> 
> My pages are all in UTF8, but I can't find a way to set this character
> set for custom generated error pages.
> 
> I've tried:
> 
>  - $r->content_type('text/html; charset = utf8');
>  - $r->err_headers_out('Content-type' =>'text/html; charset = utf8');
>  - <meta http-equiv = "Content-Type" content = "text/html; charset=utf-8" />
>  - AddDefaultCharset UTF8
> 
> to no avail - apache always overrides this with:
> 
>    Content-Type: text/html; charset=iso-8859-1
> 
> According to the apache docs for AddDefaultCharset:
> 
>         Note: This will not have any effect on the Content-Type and
>         character set for default Apache-generated status pages (such as
>         '404 Not Found' or '301 Moved Permanently') because those have
>         an actual character set (that in which the hard-coded page
>         content is written) and don't need to have a default applied.
> 
> That implies that the character set is taken from the file itself, but
> that shouldn't apply to errors generated with
> $r->custom_response($error_msg)
> 
> For now, I plan to just entity escape anything that isn't in the ASCII
> range, but is there a workaround? Should this be fixed?

this isn't a mod_perl thing, it's an httpd thing. this is from 1.3:

   http://www.mail-archive.com/modperl@apache.org/msg20549.html

it seems the same holds true in httpd 2.0, it seems.  see 
ap_send_error_response in

   modules/http/http_protocol.c

try setting subprocess_env(suppress-error-charset => 1) and see if that 
helps you at all.

--Geoff