Mailing-List: contact docs-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: docs@httpd.apache.org
From: bugzilla@apache.org
To: docs@httpd.apache.org
Subject: [Bug 55741] Documentation is served with incorrect character
 encoding
Date: Tue, 05 Nov 2013 15:43:33 +0000
Message-ID: <bug-55741-56585-fbNiz8CdS2@https.issues.apache.org/bugzilla/>
In-Reply-To: <bug-55741-56585@https.issues.apache.org/bugzilla/>
References: <bug-55741-56585@https.issues.apache.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Auto-Submitted: auto-generated
MIME-Version: 1.0

https://issues.apache.org/bugzilla/show_bug.cgi?id=3D55741

--- Comment #7 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> -=
--
(In reply to Dirkjan Ochtman from comment #6)
> (In reply to Nick Kew from comment #4)
> > In any case, it looks like a firefox issue (or a local issue).  I haven=
't
> > checked it in the latest update, but when I first worked on charset iss=
ues,
> > the HTTP spec *explicitly* made iso-9958-1 a default if no explicit
> > content-type was indicated.  Hence a browser needs, at a minimum, to ac=
cept
> > it.
>=20
> That may be so, but I think a bunch of this changed with HTML5 and new-fo=
und
> enthusiasm for standardizing actual browser behavior. Please check the W3C
> table I linked to in the description.


=E2=80=9CA bunch=E2=80=9C is very unspecific. And HTTP is almost irrelevant=
 to the issue.

As a HTML WG invited expert, pointing to the latest draft, I can say that m=
ost
Firefox locales default to WINDOWS-1252/ISO-8859-1:
http://www.w3.org/html/wg/drafts/html/master/syntax.html#determining-the-ch=
aracter-encoding

So, if  your alpha version of Firefox 27 parses that page as UTF-8, then it
must be because something causes your browser to default to UTF-8.=20

All this being said: If the page *had* declared the encoding properly, we w=
ould
not have been having this discussion. Because, as is, the page does *not*
declare any encoding in a HTML conforming way - HTML5 conformance, these da=
ys,
is regulated by HTML5.

When the browsers fails to find a encoding definition, HTML5.x instructs the
parser to default to some encoding - usually a locale default, but it could
also be a another default.

So, to Nick Kew: It is wrong to say that this is local issue. More correct =
is
that HTML5.x *requires* the browser to fallback to a local encoding when the
page - as is the the case here - fails to declare the encoding.

--=20
You are receiving this mail because:
You are the assignee for the bug.=

---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org