Bug: parse->stringify->parse get different results

[yevgenypats]

Hey There,

Found the following bug:

const qs = require('qs');
const assert = require('assert');

const str = '&=]p&Qm[UU3]={Qmm&Qm=]]&Qm[[UF3]mi]=mQvmQm;';
const obj = qs.parse(str);
const str1 = qs.stringify(obj);
const obj1 = qs.parse(str1);
assert.deepEqual(obj, obj1);

found by jsfuzz

[ljharb]

That looks like an invalid query string in the first place. (I don't think fuzz testing is a reliable approach for something like this)

specifically, the & key, and all the mismatched curly braces and square brackets.

[yevgenypats]

Hey!:) but this is why I first parse it to a valid object and then stringify again and parse again. for example you can take the following example which will produce inequality as well.

const qs = require('qs');
const assert = require('assert');

const obj = {
  'Qm[': {
    UF3: 'mQvmQm;'
  },
  Qm: {
    ']]': true,
    UU3: '{Qmm'
  }
}

const str = qs.stringify(obj);
const obj1 = qs.parse(str);
assert.deepEqual(obj, obj1);

[ljharb]

In that case, I do see that ']]' becomes '0' in the parsed code.

What do common frameworks (Rails, express, PHP) do with this query string?

[yevgenypats]

I'm not sure. but what is causing the ]] to become 0? maybe an exception would be better when you stringify an object that qs doesnt support?

[ljharb]

Yes, that's also fair. I'd be open to a PR to handle that somehow.

However, knowing what those other frameworks do would guide what the proper thing to do here is.

[yevgenypats]

Cool. I'm not sure I'll have time in the near future but maybe you can tag it as help-needed/feature and someone will weigh-in before me.