3 ms·

Does anyone know the historical justification for charset negotiation in the first place? I guess the idea was that the browser and the server would agree on wh

Does anyone know the historical justification for charset negotiation in the first place? I guess the idea was that the browser and the server would agree on what encoding they'd use and the server would auto-translate for the web visitor. But I can't imagine that ever being used in practice.

pilif 15y ago
The idea wasn't necessarily for the server to translate because back when this was invented, there was no Unicode and no UTF-8, so there might very well have been no way to losslessly translate. The client would send an Accept-Charset header to tell the server what it supports and the server would send either the content in the appropriate encoding (if available) or a "406: Not Acceptable" error.
- NelsonMinar 15y ago
  I think Unicode predates Accept-Charset. Unicode 1.0 was published late 1991. Accept-Charset was formalized in the HTTP 1.0 RFC (1996). Usage presumably predates that, but it's not described in the HTTP 0.9 docs (which say ASCII only!) http://www.w3.org/Protocols/HTTP/AsImplemented.html http://www.w3.org/Protocols/HTTP/AsImplemented.html But what really matters is widespread acceptance of Unicode and UTF-8 and that was definitely later in coming. Thanks to dchest below for referencing a transcoding server. It's interesting the HTTP/1.0 docs characterize Accept-Encoding as a way to signal the client could handle something other than ASCII and ISO-8859-1. Google started favoring UTF-8 in search result pages somewhere around 2002 or 2003.
derleth 15y ago
> Does anyone know the historical justification for charset negotiation in the first place? Back in the Old Days (say, 1995), each OS (family) would have its own variant of 'Extended ASCII': Unix had Latin-1, Windows had its own encoding mostly compatible with Latin-1, and Macintosh computers had Mac OS Roman, aka MacRoman or just macintosh. It's possible to convert most, say, French texts from any of these to any other without losing anything, but if you don't the other person will have garbage on their end. In theory, if a client said it could only handle a charset that didn't include some of the characters in the source document, you could do something like give them an HTML file that used images to represent what they didn't have. Or something.
dchest 15y ago
There was a rather popular Apache fork for Russian websites that did this http://apache.lexa.ru/english/ http://apache.lexa.ru/english/ Before content negotiation, a lot of Russian websites had multiple versions of pages with switches: KOI-8 (mostly used on *nix) / Win / DOS.

pilif 15y ago

The idea wasn't necessarily for the server to translate because back when this was invented, there was no Unicode and no UTF-8, so there might very well have been no way to losslessly translate. The client would send an Accept-Charset header to tell the server what it supports and the server would send either the content in the appropriate encoding (if available) or a "406: Not Acceptable" error.

NelsonMinar 15y ago
I think Unicode predates Accept-Charset. Unicode 1.0 was published late 1991. Accept-Charset was formalized in the HTTP 1.0 RFC (1996). Usage presumably predates that, but it's not described in the HTTP 0.9 docs (which say ASCII only!) http://www.w3.org/Protocols/HTTP/AsImplemented.html http://www.w3.org/Protocols/HTTP/AsImplemented.html But what really matters is widespread acceptance of Unicode and UTF-8 and that was definitely later in coming. Thanks to dchest below for referencing a transcoding server. It's interesting the HTTP/1.0 docs characterize Accept-Encoding as a way to signal the client could handle something other than ASCII and ISO-8859-1. Google started favoring UTF-8 in search result pages somewhere around 2002 or 2003.

derleth 15y ago

> Does anyone know the historical justification for charset negotiation in the first place? Back in the Old Days (say, 1995), each OS (family) would have its own variant of 'Extended ASCII': Unix had Latin-1, Windows had its own encoding mostly compatible with Latin-1, and Macintosh computers had Mac OS Roman, aka MacRoman or just macintosh. It's possible to convert most, say, French texts from any of these to any other without losing anything, but if you don't the other person will have garbage on their end. In theory, if a client said it could only handle a charset that didn't include some of the characters in the source document, you could do something like give them an HTML file that used images to represent what they didn't have. Or something.

dchest 15y ago

There was a rather popular Apache fork for Russian websites that did this http://apache.lexa.ru/english/ http://apache.lexa.ru/english/ Before content negotiation, a lot of Russian websites had multiple versions of pages with switches: KOI-8 (mostly used on *nix) / Win / DOS.