On Sep 18, 2017, at 19:50, Adam Roach <adam@xxxxxxxxxxx> wrote: > >> Note the HTTP server provides no content encoding headers so it's up to the app to detect. But that is not the way HTTP works. If you make servers misrepresent the content, browsers will follow what they say. “No content encoding” (I read: no charset) for text/plain is not possible, as there is a default; it means ASCII. RFC 2046 4.2.1: The default character set, which must be assumed in the absence of a charset parameter, is US-ASCII. So you sent the UTF-8 files declaring them as ASCII; it is no wonder that browsers had problems with that. Obviously, servers can easily be configured to send all RFCs as UTF-8, as all *are* UTF-8. We had a brief time (in 2006, IIRC) when that actually was the case with the IETF servers, until a random user with a BOM-polluting application got in the way. We should have used that as a teachable moment, instead of regressing to ISO 8859-1 for another decade. Grüße, Carsten