On 2012-01-07 10:48, Anne van Kesteren wrote:
On Fri, 06 Jan 2012 17:20:04 +0100, Glenn Maynard <gl...@zewt.org> wrote:
Anne: There's one related change I'd suggest. Currently, if a JSON
response says "Content-Encoding: application/json; charset=Shift_JIS",
the explicit charset will be silently ignored and UTF-8 will be used.
I think this should be explicitly rejected, returning null as the JSON
response entity body. Don't decode as UTF-8 despite an explicitly
conflicting header, or people will start sending bogus charset values
without realizing it.
I don't think there's a single media type parameter that causes fatal
error handling so I do not think that would be a good idea. E.g.
text/event-stream;charset=hz-gb-2312 will give you utf-8 decoding too.
text/html;charset=foobar will give you whatever is the default in HTML,
etc.
charset is undefined on application/json, so ignoring it is the right thing.
text/event-stream;charset=hz-gb-2312 on the other hand is invalid (as
far as I understand the spec), so if this defaults to UTF-8 this is just
an effect of the specified error handling.
Best regards, Julian
