Re: [XHR] responseType "json"

* Anne van Kesteren wrote:
>I tied it to UTF-8 to further the fight on encoding proliferation and  
>encourage developers to always use that encoding.

The fight here is for standards. You know, you read the specification,
create some content, and then that content works in all implementations
that claim to implement the specification as you would assume based on
reading the specification. You want to know how JSON content is handled
by reading the JSON specification, and not the documentation for each
and every JSON processors.

That said, there are a number of media types by now that use the "+json"
convention that's not actually defined anywhere authoriatively, and it
is common to use other media types than application/json for JSON con-
tent, like application/javascript, and the rules there vary. Should it
be possible to use the UTF-8 Unicode Signature? Types differ on that and
it seems likely that implementations do aswell.

I did not reverse-engineer the current proposal, but my impression is it
would handle "text" and "json" differently with respect to the Unicode
signature. I do not think that would be particularily desirable if true.

Anyway, given that it's difficult to tell which rules apply without some
specification for "+json" and other things, I can't find much wrong with
forcing the encoding to be UTF-8, especially because the other options
that the JSON specification allows would result in a fatal error, which
would be the same if implementations tried to detect the encoding, but
then decided they do not support, say, UTF-32 encoded JSON. But it's not
clear to me, that the Unicode signature should result in a fatal error,
if you ignore what the JSON specification says about encodings.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Sunday, 4 December 2011 20:39:18 UTC