Bug 136951 - Enabling AddDefaultCharset in default httpd.conf is wrong thing to do.
Summary: Enabling AddDefaultCharset in default httpd.conf is wrong thing to do.
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: httpd
Version: 3.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Joe Orton
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-10-23 21:21 UTC by Ronald Cole
Modified: 2007-11-30 22:07 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-10-24 10:55:14 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Ronald Cole 2004-10-23 21:21:12 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; 
SV1; .NET CLR 1.0.3705; .NET CLR 1.1.4322)

Description of problem:
Japanese documents with correct character set encoding in the meta 
tags are rendered as garbage by browsers that tend to believe Apache 
instead of the meta tags (which is pretty much most of them) because 
the default httpd.conf sets AddDefaultCharset to UTF-8.

Version-Release number of selected component (if applicable):
httpd-2.0.46-40.ent

How reproducible:
Always

Steps to Reproduce:
1.  Upgrade a fully functional RHL 7.3 Japanese website to RHEL 3.
2.  
3.
    

Actual Results:  The httpd server tells browsers that documents are 
all UTF-8 encoded, which generates lots of complaints from users who 
are looking at garbage on their screens because most browsers will 
accept the dictates of an Apache server instead of a document's meta 
tags.

Expected Results:  Seamless upgrade.

Additional info:

<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23421> argues that 
the best thing to do here is simply comment out 
the "AddDefaultCharset UTF-8" line from the httpd.conf file that is 
shipped with the RHEL3 httpd rpm.

Comment 1 Joe Orton 2004-10-24 10:55:14 UTC
Thanks for contacting us.

We agree with upstream in considering an AddDefaultCharset setting to
be the correct default.  As mentioned in the upstream bug report, it
is necessary to enforce a default charset setting in Content-Type
headers to prevent some possible cross-site-scripting security issues.

It is true that browsers are required to honour the charset from the
Content-Type header over the META tag by the HTML standards.  The
solution is to ensure that the correct charset is sent in the
Content-Type header is sent for every page; two methods which allow
this are:

1) name documents with one of the suffixes mapped by the AddCharset
settings; e.g. "page.html.jis" will get a charset of ISO-2022-JP.

2) allow users to override the AddDefaultContentType in .htaccess
files as necessary.

Of course, if you do not consider the Cross-Site-Scripting issues to
be relevant, it is also possible to remove the AddDefaultCharset
setting from httpd.conf.


Note You need to log in before you can comment on or make changes to this bug.