Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

No thanks to Mr. Crawford for not fixing the \u2028-9 issue. JSON as defined is not a subset of javascript. It is a design mistake that was pointed out to him years ago, but he is too stubborn or arrogant to fix it.


Why do you ask him without the stubborn and arrogant comment on G+ and about trailing commas? Or is indirect better?


Trailing commas would make the problem worse! If you allow trailing commas then you would break json parsing in all old version of IE. The unicode line ending problem is more subtle.

I have seen people write code like (mix javascript and some templating):

    <script>
    var prefs = <%= user_prefs.to_spec_conforming_json() %>;
    ...
The above code looks okay, but if the json is just spec conforming, then you are exposed to a potential XSS attack.

Most people that write json encoders are aware of the problem, but why publish a a spec that can potentially create serious security problems?


> If you allow trailing commas then you would break json parsing in all old version of IE.

No, you would break the evaluation of json as javascript in old versions of IE.

Use a real parser already.


I do use a real parser, but it is not possible for JSON-P.


I've always avoided JSONP, but this would seem doable. What am I missing?

    callback(JSON.parse('{ "key":"value" }'))
Or even directly parsing the string inside of the callback.


Don't use JSONP.


I suppose you have a better way to do cross-platform cross-domain APIs? Enlighten us. Facebook and Google use this method, and I assume it is because there isn't a better way.


You can use CORS [1] on browsers that support it. [2] You really should use it if at all possible given your application's constraints, so you don't have to abuse GET requests and can use a JSON parser.

[1] http://en.m.wikipedia.org/wiki/Cross-origin_resource_sharing

[2] http://caniuse.com/cors


Unfortunately CORS is not really doable if you have to support IE and need non-cookie authentication, as my company recently discovered to our sorrow. No custom headers, so goodbye to your X-Auth-Token. That has only been fixed in IE10.


Cross platform?


> you would break json parsing in all old version of IE

Why do people still care about old versions of IE?


~22% of China still uses IE6: http://www.ie6countdown.com/

Developing nations have a tendency to not use the latest and greatest. If reaching them is important for you/your product then you have to keep tracking this stuff.


> Developing nations have a tendency to not use the latest and greatest.

Attention developing nations: Chromium and Firefox are completely foss. No excuse, unless you don't have an internet connection.

In which case, what do you need a web browser for?


I'm not sure about this but a lot of software might have been written specifically for IE6 and IE6 only, which might not translate well to Chrome/Firefox, and could cost businesses a lot of money, more money than they deem its worth. There could be ActiveX controls and such which can't be ported to Chrome/Firefox without money.

This is based on my experience at UPS which used a single machine using IE6 and some form of web app to control start up and shut down procedures, or something to that effect. It had no Internet connection, only LAN I believe.

I did ask myself this question too and it does seem peculiar. After some thought, my only guess is the above!


> There could be ActiveX controls and such which can't be ported to Chrome/Firefox without money.

South Korea is a huge example of this. When online banking first came to market, the only way to do it legally in South Korea was through ActiveX controls embedded in Internet Explorer because they had specific encryption requirements in the 1990s versus what IE or other browsers supported natively.

Even as recent as last year [1] it was a big deal in elections, with at least one candidate promising to end the legal requirements and allow banks to enter the modern age of browsers.

[1] http://blogs.wsj.com/korearealtime/2012/11/13/ahn-pledges-to...


Don't they have another browser around for dealing with the rest of the world though? It's not like many modern sites are going to render correctly on IE6 these days...


But all their apps work with IE6, and who cares about people trying to view Facebook while working?


If they are off in their own totally isolated little IE6 only world, I don't get why we care about them then.


Because their workers do go view Facebook. If that's a market you need to target, you need to make it work with IE6.

(There's also the whole "they get infected with everything under the sun and make the rest of us deal with them", but that's not a visual issue.)


And if the internet stops working for them because they use IE6, will they somehow manage to upgrade?


IE10, IE11 in non-standards mode also don't accept trailing commas. I don't care if you accept trailing commas, but dear god, never emit them.


They don't, it's just convenient to make their point. Pretty much any new technology isn't directly compatible with old technology.


Probably because he's very aware of it already and people here may not be.

(Meta: Why have any conversation on an HN back-channel when there are comments open at the source?)


Meta: because the comments are closed to people with a Google account that have no problems in sharing their comment on G+ publicly


> that have no problems in sharing their comment on G+ publicly

Specially now that giving in to G+ means showing up on ads.


Isn't this a design mistake in JavaScript rather than JSON?


No, not really. The JSON standard says you can't put raw newlines in strings, and you must write \n. Why does it say it is okay to put raw unicode line_separator rather than requiring \u2028 ? Two more lines to the spec, and DC's variant of JSON would actually be a subset of Javascript. Instead we are left with an edge case that we are going to have to worry about for the next 20 years.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: