Bug#415775: RC-ness (AddDefaultCharset)
reopen 415775
retitle 415775 default setup enables AddDefaultCharset, which is considered harmful
severity 415775 important
thanks
Hi,
> I sought more opinions on this issue. People were split, and Steinar
> Gunderson brought up the good point that it doesn't make too much sense
> to specify a character encoding for a text file _within_ the same text
> file. Sure, it works for many encodings, but it doesn't work for
> UTF-16, and there are reasons one might want to use that. And some
> people were saying that <meta http-equiv> is actually the greater evil.
This argument convinced me at first, but thinking more about it, it looks
flawed. For two reasons:
- We have standards for these things. Either an HTML is W3C-compliant or it
is not. If it is, then apache must be able to parse its <meta http-equiv>
even if this tag is non-ascii. If it's not, then we shouldn't jump through
hoops to support this in the default install. Standard-broken sites can
enable AddDefaultCharset manualy.
- In our particular case, we're setting AddDefaultCharset to assume utf-8,
*not* utf-16 or any other ill charset. If charset $foobar rewrites
"<meta http-equiv>" in a way that apache can't parse, we don't gain anything
by telling apache to assume utf-8, since their charset is $foobar.
For the latter case, though, I think it'd be a good idea to add some sort of
template:
# do not uncomment unless you know what you're doing
#AddDefaultCharset something
> So for apache2 2.2.3-4, I've left the AddDefaultCharset=UTF-8 enabled
> for new installs. I _did_ stop it from creating this file in an
> existing install, which was the point of this bug.
Much better. IMHO this is no longer RC, since it doesn't suddenly break sites
on upgrade. I'd appreciate if it still could be fixed for etch, though.
--
Robert Millan
My spam trap is honeypot@aybabtu.com. Note: this address is only intended
for spam harvesters. Writing to it will get you added to my black list.
Reply to: