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):
Steps to Reproduce:
1. Upgrade a fully functional RHL 7.3 Japanese website to RHEL 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
Expected Results: Seamless upgrade.
<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.
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
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.