Repository navigation
[email protected] update changes default body-parser behaviour #687
Description
Passing arrayLimit as 0 to [email protected] parses arrays as objects with indexes instead of arrays (lib/types/urlencoded.js:99). Since extended is false by default, our default behaviour has changed.
There's also a failing test
1) bodyParser.urlencoded()
with extended option
when false
should parse multiple key instances:
Error: expected '{"user":["Tobi","Loki"]}' response body, got '{"user":{"0":"Tobi","1":"Loki"}}'
Environment information
Version: 2.2.1
Platform:
Node.js version:
Any other relevant information:
What steps will reproduce the bug?
npm run test
Activity
krzysdz commentedon Jan 3, 2026
According to ljharb/qs#537 (comment) this should have never worked in the first place.
body-parser2.0.0 changed the"simple"query parser to useqsinstead ofquerystring(PR #387), but the behaviour should be the same (see discussion in #326).I think it could be solved by increasing
arrayLimit, because it looks like with current options sparse arrays are not allowed anyway.@ljharb could you look into this?
ljharb commentedon Jan 4, 2026
Indeed, expecting arrays over 20 items should have never worked in the first place. Setting it to zero means you should never expect an array.
jonchurch commentedon Jan 5, 2026
simple mode depends on parsing as many array items as
options?.parameterLimit(default 1000), so my fix is to setarrayLimitto our parameter count 474ccd3I think we took a dep on the buggy behavior in qs itself while prototyping a backwards compatible migration from
node:querystring, somewhere around #326 (comment)it was committed in #387
the bug doesnt bite us because we just so happen to limit the input we parse another way
jonchurch commentedon Jan 5, 2026
Pr to body-parser 2.x line to fix this #689
To be released in #691
Parse URL-encoded request body with the `qs` library
Fix issues parsing form data and downloading the prototype ZIP (#151)