Re: JSON.stringify() has been "improved"

Fortunately my analysis was wrong, all systems are go! The revised serialization deals with pathological UTF which RFC 8785 anyway outlaws. Anders On 2020-09-21 05:56, Anders Rundgren wrote: Hi ES-lovers, I have co-authored a JSON canonicalization scheme, recently published as an RFC:

JSON.stringify() has been "improved"

Hi ES-lovers, I have co-authored a JSON canonicalization scheme, recently published as an RFC: https://www.rfc-editor.org/rfc/rfc8785.html The work started with ES V6 as foundation since it made things really easy. Serialization of quoted strings where taken "as is" from:

Re: Implementing an identical JSON.stringify

e. String.prototype and Object.prototype > both implement "valueOf", but only the former will fail the slot check. > > Thanks for demystifying this. I never realized it was just ducktyping > .valueOf on the object. > > ```js > Number.prototype.valueOf = () =&

Re: `ToNumber` and `ToString` invoking `toString`/`valueOf` for number/string objects? (Was: Re: Re: Implementing an identical JSON.stringify)

pe", but rather that these algorithms will call methods > by > >> specific names on objects they receive. String.prototype and > >> Object.prototype both implement "valueOf", but only the former will > fail the > >> slot check. > > > > > > Thanks for dem

`ToNumber` and `ToString` invoking `toString`/`valueOf` for number/string objects? (Was: Re: Re: Implementing an identical JSON.stringify)

tifying this. I never realized it was just ducktyping > .valueOf on the object. > > ```js > Number.prototype.valueOf = () => 0; > > JSON.stringify(1); // 1 > JSON.stringify(new Number(1)); // 0 > ``` > > I guess what confused me is that it would detect a [[NumberData]] internal > sl

Re: Re: Implementing an identical JSON.stringify

ithms will call >> methods by specific names on objects they receive. String.prototype and >> Object.prototype both implement "valueOf", but only the former will fail >> the slot check. >> > > Thanks for demystifying this. I never realized it was just duck

Re: Re: Implementing an identical JSON.stringify

bjects they receive. String.prototype and > Object.prototype both implement "valueOf", but only the former will fail > the slot check. > Thanks for demystifying this. I never realized it was just ducktyping .valueOf on the object. ```js Number.prototype.valueOf = () => 0;

Re: Implementing an identical JSON.stringify

It's very subtle, but no, that's correct per spec, and any engine that doesn't do that is buggy. When `JSON.stringify` is invoked on a number, it first performs ToNumber on number objects (which each of these are) to get the number value, which itself indirectly calls `valueOf`. The first calls

Re: Implementing an identical JSON.stringify

@gmail.com>> a écrit : >>> >>> Try `Number.prototype.valueOf.call(obj)`: it will throw a TypeError if and >>> only if `obj` has no [[NumberData]] internal slot. Ditto for String, >>> Boolean and Symbol. >>> >>> I already menti

Re: Implementing an identical JSON.stringify

`obj` has no [[NumberData]] internal slot. Ditto for String, Boolean >> and Symbol. >> >> I already mention this and demonstrate why it is not sufficient in my >> example. >> >> Reiterated plainly: >> ```js >> JSON.stringify(Reflect.construct(Num

Re: Implementing an identical JSON.stringify

> Per spec, the three expressions should produce "0", as the three objects have a [[NumberData]] internal slot (step 4 of [1]). I guess there is some discrepancy between implementation and spec for those exotic edge cases? There’s no discrepancy — they shouldn’t all produce "0", because the

Re: Implementing an identical JSON.stringify

this and demonstrate why it is not sufficient in my example. > > Reiterated plainly: > ```js > JSON.stringify(Reflect.construct(Number, [], Number)); // "0" > JSON.stringify(Reflect.construct(Number, [], String)); // TypeError > JSON.stringify(Reflect.construct(Number, [], Object)); /

Re: Implementing an identical JSON.stringify

Oh, thanks Claude, I missed that. I guess it is all replicable then. On Sat, Aug 4, 2018 at 10:28 PM Claude Pache wrote: > > > > Le 5 août 2018 à 04:14, Darien Valentine a > écrit : > > > > > > However it is ultimately not possible to replicate because there is no > possible brand test for

Re: Implementing an identical JSON.stringify

> Le 5 août 2018 à 04:14, Darien Valentine a écrit : > > > However it is ultimately not possible to replicate because there is no > possible brand test for [[BooleanData]]. Per spec, checking whether `Boolean.prototype.valueOf.call(obj)` throws will test whether an object has

Re: Re: Implementing an identical JSON.stringify

Is this a question about how/if one could replicate its behavior in theory from ES code, or are you suggesting a change to the existing behavior for these exotic cases? Assuming the former: The relevant steps are [here]( https://tc39.github.io/ecma262/#sec-serializejsonproperty). The

Re: Implementing an identical JSON.stringify

> > Try `Number.prototype.valueOf.call(obj)`: it will throw a TypeError if and > only if `obj` has no [[NumberData]] internal slot. Ditto for String, > Boolean and Symbol. I already mention this and demonstrate why it is not sufficient in my example. Reiterated plainly: ```js JS

Re: Implementing an identical JSON.stringify

> Le 5 août 2018 à 00:16, Michael Theriot a > écrit : > > `JSON.stringify` has unintuitive behavior regarding interal slots. I don’t think that anything involving an object that has a [[StringData]] internal slot but has `Number.prototype` in its prototype chain could have an

Implementing an identical JSON.stringify

`JSON.stringify` has unintuitive behavior regarding interal slots. ```js // Number with[[NumberData]] // "0" JSON.stringify(Object(Number(0))); // Number without [[NumberData]] // "{}" JSON.stringify(Reflect.construct(Object, [], Number)); // Number without [[Nu

Re: JSON.stringify

ould come from one of those groups, not ECMA. >> > >> > That applies to escaping things like `` or `]]>`, and I agree. >> But >> > as Mike Samuel mentioned, JSON strings containing U+2028 or U+2029 are >> not >> > valid JS expressions.

Re: JSON.stringify

On Wed, Sep 28, 2016 at 10:06 AM, Michał Wadas wrote: > Idea: require implementations to stringify "" as "<\uscript>". > > Benefits: remove XSS vulnerability when injecting JSON as content of >

Re: JSON.stringify

On Thu, Sep 29, 2016 at 9:25 AM, Alexander Jones wrote: > Maybe we should just make U+2028 and U+2029 valid in JS then? What other > productions in JSON are invalid syntax in JS? I don't think any other productions in JSON are invalid syntax in an Expression context. JSON places

Re: JSON.stringify

> That applies to escaping things like `` or `]]>`, and I agree. > But > > as Mike Samuel mentioned, JSON strings containing U+2028 or U+2029 are > not > > valid JS expressions. I think it would make sense for `JSON.stringify` to > > escape these. > > What is it that

Re: JSON.stringify

from one of those groups, not ECMA. > > That applies to escaping things like `` or `]]>`, and I agree. But > as Mike Samuel mentioned, JSON strings containing U+2028 or U+2029 are not > valid JS expressions. I think it would make sense for `JSON.stringify` to > escape these. What

Re: JSON.stringify

But as Mike Samuel mentioned, JSON strings containing U+2028 or U+2029 are not valid JS expressions. I think it would make sense for `JSON.stringify` to escape these. -Oriol ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org

Re: JSON.stringify

On Thu, Sep 29, 2016 at 2:09 AM, Alexander Jones wrote: > In XHTML, CDATA allows a 'more' verbatim spelling of text node content. But > the end token has to be escaped, as discussed. Despite this escaping, the > text node can contain arbitrary strings. > In XHTML, you *can*

Re: JSON.stringify

On Wed, 28 Sep 2016 19:06:31 +0200, Michał Wadas wrote: Idea: require implementations to stringify "" as "<\uscript>". Benefits: remove XSS vulnerability when injecting JSON as content of

Re: JSON.stringify

In XHTML, CDATA allows a 'more' verbatim spelling of text node content. But the end token has to be escaped, as discussed. Despite this escaping, the text node can contain arbitrary strings. In XHTML, you *can* achieve the same effect without CDATA, just by escaping XML entities. Again, and

Re: JSON.stringify

Without CDATA you have to encode script bodies properly. With CDATA you have to encode script bodies properly. What problem did CDATA solve? On Sep 28, 2016 8:03 PM, "Alexander Jones" wrote: > They do solve the problem. You encode your entire JS *before* pasting it, > encoding

Re: JSON.stringify

They do solve the problem. You encode your entire JS *before* pasting it, encoding `]]>` and nothing more, and the XML document's text node contains the unadulterated text, which the JS parser also sees. It's perfect layer isolation. Ye olde HTML can't do that because there is no escaping

Re: JSON.stringify

I agree it's subideal which is why I work to address problems like this in template systems but ad-hoc string concatenation happens and embeddable sub-languages provide defense-in-depth without sacrificing correctness. CDATA sections solve no problems because they cannot contain any string that

Re: JSON.stringify

ECMAScript, while highly used in web browsers, should really not care about HTML constructs. That's where WHATWG and W3C come in. I suggest this type of feature should come from one of those groups, not ECMA. On Wed, Sep 28, 2016 at 11:54 AM, Alexander Jones wrote: > Hi Michał >

Re: JSON.stringify

Hi Michał Embedding a JSON literal into HTML involves first encoding to JSON then encoding that into HTML. Two stages which must not be confused. The 'encoding into HTML' part is best done in XHTML with CDATA, and the encoding method is taken care of by whichever XML-generating library you're

Re: JSON.stringify

Actually CDATA suffer the same issue - for string "]]>". Mike Samuel has a very strong point here. And by saying "it's antipattern, don't do this" we will not make old vulnerable code go away. And we have a very good way to stop people from shooting their own feet - for free. On 28 Sep 2016 8:31

Re: JSON.stringify

That's awful. As you say, it's an antipattern, no further effort should be spent on this. JSON produced by JavaScript has far more general uses than slapping directly into a script tag unencoded, so no-one else should have to see this. Also, there are many other producers of JSON than JavaScript.

Re: JSON.stringify

I think defining an easy way to produce embeddable JSON is a great idea, but it's not quite that simple. https://github.com/OWASP/json-sanitizer#output captures some requirements that I came up with for embedding JSON in HTML: """ The output is well-formed JSON as defined by RFC 4627. The output

Re: String.prototype.replace() problems with JSON.stringify() and serialization of Objects

'0101'.replace('0', function(){return 1}) == '1101' so your last two are the same: replace(string, callback) - called one time, using the first indexOf and replacing it invoking the callback replace(string, string) - called one time, using the first indexOf and replacing it via provided string

Re: String.prototype.replace() problems with JSON.stringify() and serialization of Objects

You can also do a split-join to get a literal replace. I'll sell this for {cost}..split({cost}).join($5.00); I'll sell this for $5.00. On Tue, Jul 29, 2014 at 9:36 AM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: '0101'.replace('0', function(){return 1}) == '1101' so your last

RE: String.prototype.replace() problems with JSON.stringify() and serialization of Objects

Subject: Re: String.prototype.replace() problems with JSON.stringify() and serialization of Objects To: andrea.giammar...@gmail.com CC: es-discuss@mozilla.org You can also do a split-join to get a literal replace. “I’ll sell this for {cost}.”.split(“{cost}”).join(“$5.00”); “I’ll sell

Re: String.prototype.replace() problems with JSON.stringify() and serialization of Objects

On Mon, Jul 28, 2014 at 10:29 PM, Christoph Martens cmarten...@gmail.com wrote: On 28.07.2014 17:24, Rick Waldron wrote: On Mon, Jul 28, 2014 at 11:16 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 7/28/14, 11:09 AM, Rick Waldron wrote: var y = x.replace('{{blob}}', function() {

Re: String.prototype.replace() problems with JSON.stringify() and serialization of Objects

Of course it's a hack :-) So, moving forward, it'd have to be an extra method on strings, that only provides a small change in behavior. It's probably not going to happen because it's such a small change. Potentially a S.p.replaceAll which has the same behavior as split-join in that: a b a c a

RE: String.prototype.replace() problems with JSON.stringify() and serialization of Objects

, 29 Jul 2014 14:00:22 -0700 Subject: Re: String.prototype.replace() problems with JSON.stringify() and serialization of Objects To: waldron.r...@gmail.com CC: es-discuss@mozilla.org Of course it's a hack :-) So, moving forward, it'd have to be an extra method on strings, that only provides

Re: String.prototype.replace() problems with JSON.stringify() and serialization of Objects

`' ​ -- From: f.bagna...@gmail.com Date: Tue, 29 Jul 2014 14:00:22 -0700 Subject: Re: String.prototype.replace() problems with JSON.stringify() and serialization of Objects To: waldron.r...@gmail.com CC: es-discuss@mozilla.org Of course it's a hack :-) So, moving forward, it'd have to be an extra

Re: String.prototype.replace() problems with JSON.stringify() and serialization of Objects

not move towards better APIs? - Alex From: f.bagna...@gmail.com Date: Tue, 29 Jul 2014 09:49:44 -0700 Subject: Re: String.prototype.replace() problems with JSON.stringify() and serialization of Objects To: andrea.giammar...@gmail.com CC: es-discuss@mozilla.org You can also do a split

Re: String.prototype.replace() problems with JSON.stringify() and serialization of Objects

`'.replace('foo', '$`', 'rg') // '$` bar`' ​ -- From: f.bagna...@gmail.com Date: Tue, 29 Jul 2014 14:00:22 -0700 Subject: Re: String.prototype.replace() problems with JSON.stringify() and serialization of Objects To: waldron.r...@gmail.com CC: es-discuss

Re: String.prototype.replace() problems with JSON.stringify() and serialization of Objects

`' ​ -- From: f.bagna...@gmail.com Date: Tue, 29 Jul 2014 14:00:22 -0700 Subject: Re: String.prototype.replace() problems with JSON.stringify() and serialization of Objects To: waldron.r...@gmail.com CC: es-discuss@mozilla.org Of course it's a hack :-) So, moving forward, it'd have to be an extra

RE: String.prototype.replace() problems with JSON.stringify() and serialization of Objects

= title.replace('foo', data);. And one more - template strings are just sugar for the concatenation, and the subject is about the replacements. ​ - Alex From: waldron.r...@gmail.com Date: Tue, 29 Jul 2014 16:32:32 -0700 Subject: Re: String.prototype.replace() problems with JSON.stringify

String.prototype.replace() problems with JSON.stringify() and serialization of Objects

is a simple indexOf() and substr(). var data = func.toString(); // Inside an engine, this would be a JSON.stringify(environment); or similar var x = 'This is a simple {{blob}}'; var y = x.replace('{{blob}}', data, true); // note the suggested optional flag An example implementation I made

RE: String.prototype.replace() problems with JSON.stringify() and serialization of Objects

@mozilla.org Subject: String.prototype.replace() problems with JSON.stringify() and serialization of Objects Hey everyone, I wanted to ask if there's a plan to offer something like String.prototype.replace(search, replace, stringmode) as an alternative API

Re: String.prototype.replace() problems with JSON.stringify() and serialization of Objects

. -- Date: Mon, 28 Jul 2014 14:52:56 +0200 From: cmarten...@gmail.com To: es-discuss@mozilla.org Subject: String.prototype.replace() problems with JSON.stringify() and serialization of Objects Hey everyone, I wanted to ask if there's a plan to offer something

Re: String.prototype.replace() problems with JSON.stringify() and serialization of Objects

On 7/28/14, 11:09 AM, Rick Waldron wrote: var y = x.replace('{{blob}}', function() { return data; }); In fairness, that's the sort of thing that gives off a WAT smell. Code like this without a comment that explains the indirection is just asking someone to simplify it, breaking it

Re: String.prototype.replace() problems with JSON.stringify() and serialization of Objects

On Mon, Jul 28, 2014 at 11:16 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 7/28/14, 11:09 AM, Rick Waldron wrote: var y = x.replace('{{blob}}', function() { return data; }); In fairness, that's the sort of thing that gives off a WAT smell. Code like this without a comment that

Re: String.prototype.replace() problems with JSON.stringify() and serialization of Objects

On 28.07.2014 17:24, Rick Waldron wrote: On Mon, Jul 28, 2014 at 11:16 AM, Boris Zbarsky bzbar...@mit.edu mailto:bzbar...@mit.edu wrote: On 7/28/14, 11:09 AM, Rick Waldron wrote: var y = x.replace('{{blob}}', function() { return data; }); In

JSON.stringify and symbols

As specified in the latest draft: 1. JSON.stringify(symbol) returns undefined. 2. JSON.stringify([symbol]) returns [null]. 3. JSON.stringify(object) skips any symbol-keyed properties on the object. So far, so good, I guess. A little wonky maybe, but JSON doesn't have symbols, so sure

Re: JSON.stringify and symbols

JSON.stringify also skips function-valued properties, which seems even more weird. I think this is fine as long as it can be overridden by replacers and resolvers. On Mon, Jun 30, 2014 at 11:37 AM, Jason Orendorff jason.orendo...@gmail.com wrote: As specified in the latest draft: 1

Re: JSON.stringify and symbols

`undefined`, or an object with a toJSON which returns undefined. [1]: http://jsfiddle.net/MRUj6/ On Mon, Jun 30, 2014 at 12:55 PM, Mark S. Miller erig...@google.com wrote: JSON.stringify also skips function-valued properties, which seems even more weird. I think this is fine as long as it can

Re: JSON.stringify(undefined)

Barry, Tim: Right, undefined is not valid JSON. Thanks! On Jul 16, 2012, at 6:57 , Barry van Oudtshoorn wrote: I would assume that this is because the JSON grammar doesn't include undefined as an acceptable value -- JSON.stringify({foo:undefined}) returns {}. Perhaps JSON.stringify

JSON.stringify(undefined)

... returns undefined. Shouldn’t it be undefined? -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org

Re: JSON.stringify(undefined)

I would assume that this is because the JSON grammar doesn't include undefined as an acceptable value -- JSON.stringify({foo:undefined}) returns {}. Perhaps JSON.stringify(undefined) should, however, return -- in my view, this would make more sense. On 16/07/12 10:48, Axel Rauschmayer wrote

RE: The name and length property of JSON.parse and JSON.stringify

) { return true; } } runTestCase(testcase); My best, Dave On Mon, Mar 12, 2012 at 8:33 AM, 程劭非 csf...@gmail.commailto:csf...@gmail.com wrote: Hi all, Just noticed that there is no description about name and length property of JSON.parse and JSON.stringify in ES5. Are they implement

Re: The name and length property of JSON.parse and JSON.stringify

On Mon, Mar 12, 2012 at 8:33 AM, 程劭非 csf...@gmail.com wrote: Hi all, Just noticed that there is no description about name and length property of JSON.parse and JSON.stringify in ES5. Are they implement-dependent? (I saw test262 require JSON.stringify.length to be 3, but no such case

Re: The name and length property of JSON.parse and JSON.stringify

Thank you. It's my fault that I didn't read it carefully. 2012/3/12 Lasse Reichstein reichsteinatw...@gmail.com On Mon, Mar 12, 2012 at 8:33 AM, 程劭非 csf...@gmail.com wrote: Hi all, Just noticed that there is no description about name and length property of JSON.parse and JSON.stringify

Re: sort keys with JSON.stringify()

be equal). Perhaps I am over simplifying his question or I misunderstand your response. On Sep 11, 2011 3:05 PM, Douglas Crockford doug...@crockford.com wrote: On 11:59 AM, Felipe Gasper wrote: Is it possible to get sorted keys: {a:1,c:3} …from running JSON.stringify when declaring an object

Re: sort keys with JSON.stringify()

On 9/12/11 10:07 AM, Brian Kardell wrote: But Doug, just to clarify: You mean that the parsed objects create no predictable insertion order right? It is actually possible to use replacer to serialize keys in a particular order, and that might be enough for what he is looking for (if two

Re: sort keys with JSON.stringify()

I think depth shouldn't be the problem. At the crux of is is that that technique uses iteration order which has a bit of a defacto standard that would guarantee that certain classes of object would serialize objects with the same data in the same way. It has problems on the fringes though...if

Re: sort keys with JSON.stringify()

, that’s always been my understanding. -F On 9/10/11 9:32 PM, Cryptic Swarm wrote: run it through something like this: function sortKeys(obj) { var ret = {} Object.keys(obj).sort().forEach(function(name) { ret[name] = obj[name] }) return ret } before passing it to JSON.stringify On Sat

Re: sort keys with JSON.stringify()

, Is it possible to get sorted keys: {a:1,c:3} …from running JSON.stringify when declaring an object thus: {c:3,a:1} ?? -FG ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: sort keys with JSON.stringify()

On 11:59 AM, Felipe Gasper wrote: Is it possible to get sorted keys: {a:1,c:3} …from running JSON.stringify when declaring an object thus: {c:3,a:1} JSON objects are unordered. If order is important, then use an array. ___ es-discuss mailing list

Re: sort keys with JSON.stringify()

On 9/11/11 5:05 PM, Douglas Crockford wrote: On 11:59 AM, Felipe Gasper wrote: Is it possible to get sorted keys: {a:1,c:3} …from running JSON.stringify when declaring an object thus: {c:3,a:1} JSON objects are unordered. If order is important, then use an array. That’s actually my point

sort keys with JSON.stringify()

Hello, Is it possible to get sorted keys: {a:1,c:3} …from running JSON.stringify when declaring an object thus: {c:3,a:1} ?? -FG ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: sort keys with JSON.stringify()

().forEach(function(name) { ret[name] = obj[name] }) return ret } before passing it to JSON.stringify On Sat, Sep 10, 2011 at 9:14 PM, Felipe Gasper fel...@felipegasper.com mailto:fel...@felipegasper.com wrote: Hello, Is it possible to get sorted keys: {a:1,c:3

Re: A few more deviations in JSON.stringify

Oliver Hunt wrote: The specified behaviour of the abstract operation Quote in section 15.12.3 states that only characters with a unicode number less than or equal to 0x1f should be escaped. My testing found that json2.js escapes a number of other ranges of characters in unicode:

Re: Deviations between json2.js and the currently specified behaviour of JSON.stringify

On Jun 5, 2009, at 12:01 PM, Allen Wirfs-Brock wrote: I must be dense this morning but I don’t see how the two calls to [[Get]] occurs in the algorithm. The first call to [[Get]] for a property key in object holder occurs in step 1 of Str. How does the second call occur? The only place I

JSON.stringify replacer array semantics

The spec for JSON doesn't describe the exact behaviour of the replacer argument to stringify when the replacer is an array. The relevant text (from 15.12.3) is If Type(replacer) is object and the [[Class]] internal property of replacer is Array, then Let K be an internal List

JSON.stringify 15.12.3, Str algorithm 9a

In describing the abstract operation Str(key, holder), the spec says 9. If Type(value) is number a. If value is finite then return value. b. else, return null Perhaps I am misreading, but this looks like a bug to me, since Str should return a string. -- Robert Sayre I would have written

RE: JSON.stringify 15.12.3, Str algorithm 9a

, March 05, 2009 10:03 AM To: es-discuss Subject: JSON.stringify 15.12.3, Str algorithm 9a In describing the abstract operation Str(key, holder), the spec says 9. If Type(value) is number a. If value is finite then return value. b. else, return null Perhaps I am misreading, but this looks like

Re: The name JSON.stringify

On Nov 16, 2008, at 11:57 PM, Peter Michaux wrote: The name JSON.stringify seems a little too Web 2.0 cool to me. Hardly. It's hacker dictionary material, old sk00l. Is there any reason a more usual and serious sounding option like serialize was not used? Ugh, Web 1.0 my-first-Java