Array like params in a application/x-www-form-urlencoded form post get parsed wrong.

[stubar]

I think this has happened in a recent update as it used to work.

My test was matching a post body like so...

.post('/some-api',{
                    "orderId": "AGOODORDERID",
                    "consignmentTracking": "CONSIGNMENTTRACKING",
                    "storeId": "8100",
                    "directReturn": "false",
                    "refundWarningAck": "true",
                    "refundDetailsData[0].entryNo": "0",
                    "refundDetailsData[0].returnableQuantity": "2",
                    "refundDetailsData[0].expectedQuantity": "1",
                    "refundDetailsData[0].reason": "IncorrectItemReceived",
                    "refundDetailsData[0].notes": "some free text here"
                })

Which worked fine. However after an update it stopped working so I thought I'd change the 2nd param from a match object to a function and have a look at the passed body param, this revealed that the above array has been parsed to the following...

                    "refundDetailsData": [
                      "0",
                      "2",
                      "1",
                      "IncorrectItemReceived",
                      "some free text here"
                    ]

I am working around it by testing the raw body in this.body using a serialize function like so...

function(body) {
                  return this.body === serialize({
                    "orderId": "AGOODORDERID",
                      "consignmentTracking": "CONSIGNMENTTRACKING",
                      "storeId": "8100",
                      "directReturn": "false",
                      "refundWarningAck": "true",
                      "refundDetailsData[0].entryNo": "0",
                      "refundDetailsData[0].returnableQuantity": "2",
                      "refundDetailsData[0].expectedQuantity": "1",
                      "refundDetailsData[0].reason": "IncorrectItemReceived",
                      "refundDetailsData[0].notes": "some free text here"
                  })
}

[gr2m]

can you please identify the version when it broke?
And could you please create a testcase that reproduces the problem on runkit, like this one? https://runkit.com/gr2m/5a2b2a9b890d1b00120eada4

that will help us to help you :)

Alternatively you coudl start a pull request with a failing test case that reproduces the problem that would be 💯 🏆

[stubar]

OK I'm going to try a pull request. I've just done some rolling back and I can confirm that the version that broke this is 9.1.1

[stubar]

I've made a failing test case and thought I would do some investigating as to why it fails. I have found that the point at which the parsing fails is
lib/match_body.js:30

body = qs.parse(body);

I assume the qs upgrade on the 16th Nov last year caused this change in behaviour. Looking at qs it does have a lot of support for object and array parsing. However I think the weird thing about my use case is it is sending object arrays. Maybe qs could be enhanced to parse arrays of objects eg "arrayLike1[0].fieldA": "0"
or just not try and smart parse them.
I will get in touch with the qs guys next. FWIW this is my failing test case

test('array like urlencoded form posts are correctly parsed', function(t) {

  nock('http://encodingsareus.com')
      .post('/', {
        "arrayLike[0].fieldA": "0",
        "arrayLike[0].fieldB": "data",
        "arrayLike[0].fieldC": "value"
      })
      .reply(200);

  mikealRequest({
    url: 'http://encodingsareus.com/',
    method: 'post',
    form: {
      "arrayLike[0].fieldA": "0",
      "arrayLike[0].fieldB": "data",
      "arrayLike[0].fieldC": "value"
    }
  }, function(err, res) {
    if (err) throw err;
    assert.equal(res.statusCode, 200);
    t.end();
  });
});

[gr2m]

thanks, keep us posted, and maybe get a pull request going with the failing pull request?

[stubar]

OK I've submitted a PR

[stubar]

I've just started investigating qs and have found the solution is potentially very simple...

body = qs.parse(body, { allowDots: true });

By adding the allowDots setting to the line discussed, the arraylike params i was feeding in work again. Not sure how I missed this in the qs api doc before. I just have to alter my nock match object to ...

{
          arrayLike: [
            {
              "fieldA": "0",
              "fieldB": "data",
              "fieldC": "value"
            }
          ]
}

All tests are passing when I add this. Do you want to bake this setting in or make it an option to the nock call that get's forwarded?

[MathieuDerelle]

I think the correct syntax is

                    "refundDetailsData[0][entryNo]": "0",
                    "refundDetailsData[0][returnableQuantity]": "2",
                    "refundDetailsData[0][expectedQuantity]": "1",
                    "refundDetailsData[0][reason]": "IncorrectItemReceived",
                    "refundDetailsData[0][notes]": "some free text here"

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. We try to do our best, but nock is maintained by volunteers and there is only so much we can do at a time. Thank you for your contributions.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue and add a reference to this one if it’s related. Thank you!