- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Sat, 07 Jan 2012 11:30:42 +0100
- To: Anne van Kesteren <annevk@opera.com>
- CC: public-webapps@w3.org
On 2012-01-07 10:48, Anne van Kesteren wrote: > On Fri, 06 Jan 2012 17:20:04 +0100, Glenn Maynard <glenn@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
Received on Saturday, 7 January 2012 10:57:53 UTC