Bug 136951 - Enabling AddDefaultCharset in default httpd.conf is wrong thing to do.
Enabling AddDefaultCharset in default httpd.conf is wrong thing to do.
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: httpd (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Joe Orton
Depends On:
  Show dependency treegraph
Reported: 2004-10-23 17:21 EDT by Ronald Cole
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-10-24 06:55:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Ronald Cole 2004-10-23 17:21:12 EDT
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):

How reproducible:

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.

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 06:55:14 EDT
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.