Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Comments in JSON

fadefade.com

Post reply on HN
Print view View original

71–80 of 180 posts

Re: Comments in JSON

#71

Post by NathanKP »

IanCal wrote: post #52
NathanKP wrote: post #35

Earlier quoted context omitted.

I've actually never developed anything serious in Rails. I just don't like the framework, and the performance of Rails leaves a lot to be desired in my opinion. I'm a 100% Node.js convert these days. But I do like the Rails convention of using YAML format and have adopted that in my own code as much as possible.

I think he's referring to the rails YAML exploit [0] because you can use yaml to create objects, like this: --- !ruby/hash:ActionDispatch::Routing::RouteSet::NamedRouteCollection 'foo; eval(eval(puts '=== hello there'.inspect);': !ruby/object:OpenStruct table: :defaults: {} Allowing people to run arbitrary code on rails servers. [0] http://rubysource.com/anatomy-of-an-exploit-an-in-depth-look...

Yeah, I had read about that. One more reason not to send YAML over the wire. YAML makes great sense for your internal configuration files and internal data structures where you need comments and readability. YAML is perfectly safe here because chances are you aren't going to be exploiting yourself by putting malicious objects in your YAML.

But for over the wire communication, JSON makes more sense than YAML, not only because parsing unsafe YAML from an untrusted client could cause exploits like you mentioned, but also because YAML is dependent on indentation and line breaks, and therefore makes communication with the client side much more awkward than just sending JSON to the client or receiving JSON from it.

Re: Comments in JSON

#72

Post by IanCal »

treerex wrote: post #10
ygra wrote: post #6

Earlier quoted context omitted.

Not really defined, but since an object is defined as an unordered collection of key/value pairs, a conforming parser could probably shuffle the pairs before parsing them.

I suppose it could, but the point of the object being defined as an unordered collection is because the most straight-forward way of implementing this is through a hash table, where the order of the keys cannot be guaranteed without additional work. I'm sure they didn't consider a parser randomly permuting the lexical order of the pairs as something a sane person would do.

Well it could perfectly sensibly do this:

    if not key in hash:
        hash[key] = value
That's a sensible approach, valid as per the spec.

> I'm sure they didn't consider a parser randomly permuting the lexical order of the pairs as something a sane person would do.

It could sort the keys, in which case the order is no longer guaranteed (again this doesn't seem insane).

The proposal is to rely on undefined behaviour for comments. I'm amazed we're still talking about this.

Re: Comments in JSON

#73

Post by jerf »

avolcano wrote: post #20
phpnode wrote: post #17

Earlier quoted context omitted.

Crockford's rationale for not supporting comments is that people use them to add meta data to the object (e.g. type annotations) which makes it hard to consume with different parsers.

Trusting the community to do the right thing is better than handicapping your users. Regardless, of course, people add metadata to JSON already - there's zero reason you can't "_type": "int". It's a completely arbitrary reason.

"Trusting the community to do the right thing is better than handicapping your users."

And the "community" in question had repeatedly and grossly demonstrated itself to be unworthy of such trust.

Crockford was not hypothesizing that this might happen, he'd seen it. Repeatedly. If you want to argue against it even so, fine, but bear in mind that is what you are arguing against, real pain that real people experienced, not mere possibilities.

Re: Comments in JSON

#74

Post by TomasSedovic »

RHSeeger wrote: post #67
sehrope wrote: post #24

Earlier quoted context omitted.

Or just use YAML[1]. It's a super set of JSON, includes comments, nicely formatted lists, and is (IMHO) much easier on the eyes. [1]: http://en.wikipedia.org/wiki/Yaml

YAML is not a superset of JSON, it's a totally different format.

According to the spec, YAML 1.2 is:

"The primary objective of this revision is to bring YAML into compliance with JSON as an official subset."

http://yaml.org/spec/1.2/spec.html

If I understand it correctly, the earlier versions were close but not 100% compatible.

Re: Comments in JSON

#75

Post by bct »

RHSeeger wrote: post #67
sehrope wrote: post #24

Earlier quoted context omitted.

Or just use YAML[1]. It's a super set of JSON, includes comments, nicely formatted lists, and is (IMHO) much easier on the eyes. [1]: http://en.wikipedia.org/wiki/Yaml

YAML is not a superset of JSON, it's a totally different format.

It's both.

Re: Comments in JSON

#76

Post by sehrope »

RHSeeger wrote: post #67
sehrope wrote: post #24

Earlier quoted context omitted.

Or just use YAML[1]. It's a super set of JSON, includes comments, nicely formatted lists, and is (IMHO) much easier on the eyes. [1]: http://en.wikipedia.org/wiki/Yaml

YAML is not a superset of JSON, it's a totally different format.

YAML 1.2 is a super set of JSON. Check out the spec itself: http://www.yaml.org/spec/1.2/spec.html#id2759572

Re: Comments in JSON

#77

Post by NathanKP »

rubinelli wrote: post #45
NathanKP wrote: post #23

This hack, while nice, is still just a work around. I highly recommend that if you can, in as many places as possible use YAML instead of JSON. JSON works great for on the fly communication with frontends that are running JavaScript, or for communication between JavaScript processes like Node.js servers. But for configuration files and other things that need comments YAML is many times better, both for it's clean, Ma…

I used some YAML to configure internal systems, and the impression of my teammates was that it was a bit fragile. Maybe we were using it wrong?

It is dependent on a specific indentation format which is one thing I dislike about it. But if you configure your vim or whatever editor you use to properly indent YAML files you should have few issues with fragility.

Even with indentation problems, the time saved in not typing curly brackets, extra quotation marks, and commas, and the time saved in not having to visually parse these when reading YAML more than makes up for the occasional data structure bug caused by bad indentation.

Re: Comments in JSON

#78

Post by zemo »

if I ever saw this in a project, I would remove those comments in a heartbeat. The behavior here is specific to the json parser. JavaScript is not the entirety of programming.

It does break the json parser in the Go standard library, in a totally nonobvious way: http://play.golang.org/p/BsDd47vWna

I would be surprised if it doesn't break many parsers, especially json parsers in static languages. If you want that sort of behavior, don't use json.

Re: Comments in JSON

#79

Post by TranceMan »

jaredmcateer wrote: post #29
LinaLauneBaer wrote: post #11

There is a interview with the inventor of JSON somewhere. In that interview he explained why he did not allow comments in JSON like in XML. He said - if I remember correctly - that it was intentional to not have comments in JSON. The reason way that comments could be misused to add additional information for a parser. For example in XML you could use comments and a special parser could use these comments to create co…

Yes the JSON spec was designed with interoperability in mind, I don't believe Crockford claims to have invented JSON, merely discovered it. That said if you want your Static JSON objects to have comments, just pipe the JSON object through a minifier to strip comments before parsing.

You are correct - confirmed in this video: Lessons of JSON

'A recent (and short) IEEE Computing Conversations interview with Douglas Crockford about the development of JavaScript Object Notation (JSON) offers some profound, and sometimes counter-intuitive, insights into standards development on the Web.'

http://inkdroid.org/journal/2012/04/30/lessons-of-json/

{ Thank you Douglas for your vision :) }

Re: Comments in JSON

#80

Post by NathanKP »

breck wrote: post #54
NathanKP wrote: post #23

This hack, while nice, is still just a work around. I highly recommend that if you can, in as many places as possible use YAML instead of JSON. JSON works great for on the fly communication with frontends that are running JavaScript, or for communication between JavaScript processes like Node.js servers. But for configuration files and other things that need comments YAML is many times better, both for it's clean, Ma…

While on the topic of encodings (I'm a huge encodings geek), let me plug a new one we recently discovered called Space ( https://github.com/nudgepad/space ). It is dead simple and has the nice feature that it is extraordinarily easy for both humans and machines to read and write.

It is definitely very minimalist. Personally I have issues parsing it visually though, because the indentation of only one space makes it hard to differentiate inner data structures particularly on a large screen with small fonts. Additionally the lack of a division character other than space between the key and the value makes reading each key value pair much harder because the key and value tend to run together visually.
Post reply on HN