square brackets confuse the parser

[manuxio]

Hello,
while parsing a body like the following, qs fails:

buttons[commands.identifier_orders_merge_action|{"orders":["47441","47440"]}]=Unisci+ordini

This becomes something like:

'buttons[commands.identifier_orders_merge_action|{"orders":': { '"47441","47440"': 'Unisci ordini' }

while it should be something more similar to this:

'buttons[commands.identifier_orders_merge_action|{"orders":{ '"47441","47440"}]': 'Unisci ordini'

[ljharb]

I agree this is mis-parsed, but why are you using | as a delimiter, and why are you sending JSON in a query string??

[manuxio]

I don't think this really matters...
Anyway... "|" is as good as any other delimiter.
It's not used in a querystring, it's used in a post field.
I found the bug while using body-parser.

Why is it json?
Couldn't think of anything better to carry some data in the property name of an object.

I need the final object to look like this:

{
"propName": "value"
}

one single prop. No more.

the only way to carry some data is to put in the propName (value is limited to 20 chars)

Oh, well, its a long story... I might encode the json string... but the bug would still persist!

m.

[ljharb]

would [propName]=value work?

[manuxio]

As long as propName has no limit to what characters it can contain.
If propName can be: "my name|{"data":["one","two","three"]}" then it's ok with me.
I don't think there should be any constraint.
If a propName works in js, it should be parsable by qs.

[ljharb]

It has some limits that are due to the browser's query string standards, and that, not JS, determines what must work or not.

It looks like the square and curly brackets are what causes issues here, since '[my name|{"data":["one","two","three"]}]=value' parses to { '[my name|{"data":': { '"one","two","three"': 'value' } }.

Additionally, if you start with the JS object you want, then { 'my name|{"data":["one","two","three"]}': 'value' } stringifies to 'my%20name%7C%7B%22data%22%3A%5B%22one%22%2C%22two%22%2C%22three%22%5D%7D=value' which does not successfully round trip. In other words, while the exact string contents of the query string aren't necessarily as permitting as you want them to be, the lack of a round trip here is indeed a bug that needs fixing.