On 2017-09-18 21:17, Carsten Bormann wrote:
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.
This was overruled by
<https://www.greenbytes.de/tech/webdav/rfc2616.html#rfc.section.3.7.1.p.4>,
making the default ISO-8859-1. That mistake was fixed in RFC 7231, and
also the clause you cited was obsoleted by
<https://www.greenbytes.de/tech/webdav/rfc6657.html>.
Obviously, servers can easily be configured to send all RFCs as UTF-8, as all *are* UTF-8.
Yes.
But that doesn't help when that metadata is not available (such as after
"save as").
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.
Details, please.
Best regards, Julian