Re: [XHR] responseType "json"
* Henri Sivonen wrote: >Browsers don't support UTF-32. It has no use cases as an interchange >encoding beyond writing evil test cases. Defining it as a valid >encoding is reprehensible. If UTF-32 is bad, then it should be detected as such and be rejected. The current idea, from what I can tell, is to ignore UTF-32 exists, and treat content that clearly is UTF-32 as UTF-16-encoded, which is much worse, as some components are likely to actually detect UTF-32, they would disagree with other components, and that tends to cause strange bugs and security issues. Thankfully, that is not a problem in this particular case. -- Björn Höhrmann · mailto:bjo...@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/
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:bjo...@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/
Re: [XHR] responseType "json"
On 2011-12-04 16:52, Anne van Kesteren wrote: On Fri, 02 Dec 2011 17:03:37 +0100, Henri Sivonen wrote: Does anyone actually transfer JSON as UTF-16? Note that you cannot transmit UTF-16 JSON from a page (sending text is UTF-8 only) so not being able to receive it either seems fine. I actually think that we should make "text" UTF-8-only too to enforce this symmetry. I think you're confusing client abilities with server abilities. Just because XHR can't *send* Json as UTF-16 doesn't mean servers don't send it to clients. It appears this needs more research. Best regards, Julian
Re: [XHR] responseType "json"
On Fri, 02 Dec 2011 17:03:37 +0100, Henri Sivonen wrote: Does anyone actually transfer JSON as UTF-16? Note that you cannot transmit UTF-16 JSON from a page (sending text is UTF-8 only) so not being able to receive it either seems fine. I actually think that we should make "text" UTF-8-only too to enforce this symmetry. -- Anne van Kesteren http://annevankesteren.nl/
Re: Enable compression of a blob to .zip file
On 12/4/11 12:33 AM, Julian Reschke wrote: On 2011-12-03 19:43, Charles Pritchard wrote: ... If there were a mime type that were more appropriate for compressed/non-compressed use, would it simply be: "image/svg" ? I think the obvious choice would be "image/svgz", which should be really short, as it can be defined as gipped-wrapped image/svg+xml. I'll try to get this continued in a decent manner on www-svg. As for the root of this topic, compressing a blob -- I don't think packaging should be done on the UA side. There are so many different ways that zip archives are presented, if the UA were responsible, I'd still need to go back to using work-arounds when I come across a zip archive that has a flag unrecognized by the UA. I'd like to revisit the issue later, as I would so very much like to see round trip base64 and deflate methods exposed to the scripting environment. -Charles
Re: Enable compression of a blob to .zip file
On 2011-12-03 19:43, Charles Pritchard wrote: ... If there were a mime type that were more appropriate for compressed/non-compressed use, would it simply be: "image/svg" ? I think the obvious choice would be "image/svgz", which should be really short, as it can be defined as gipped-wrapped image/svg+xml. Best regards, Julian
