K6: samples html_form_post.js fails

[stevenebutler]

K6 http.post method isn't correctly encoding a list of values assigned to a key in an object.

const form_data = {
    comment: "Hello world!",
    topping: [
        'onion',
        'bacon',
        'cheese'
    ]
};

The simplest way to see this is to run the sample at
https://github.com/loadimpact/k6/blob/master/samples/html_form_post.js and note that it fails.

The list of toppings should be passed as multiple values for the same key, but it is instead having the values stringified and passed as one value.

With this issue, it's difficult to pass multiple select check boxes with the same name or multi-selections in a select.

Environment

• k6 version: k6 v0.28.0 (2020-09-24T14:33:59+0000/v0.28.0-0-gdee9c4ce, go1.14.9, linux/amd64)
• OS and version: Both windows 10 and Linux K6
• Docker version and image, if applicable:

Expected Behavior

The topping values should be encoded as
topping=onion&topping=bacon&topping=cheese
and the sample should pass all checks.

Actual Behavior

Test case fails because the topping values are encoded as (and URI encoded)
topping=[onion bacon cheese]

Steps to Reproduce the Problem

1. Copy sample from https://github.com/loadimpact/k6/blob/master/samples/html_form_post.js locally or clone the git repository
2. k6 run samples/html_form_post.js
3. Observe test failure outcome

[na--]

Thanks for reporting this, I'm not sure how nobody noticed we had a wrong example for 4 years... :sweat_smile:

[na--]

For more details, k6 doesn't deal well with complex types when it tries to urlencode them. It really can't deal with that, since there isn't a standard for how to encode maps and arrays into URL parameters for application/x-www-form-urlencoded requests. PHP would have sent topping as topping[]=onion&topping[]=bacon&topping[]=cheese, for example, and as you say, other languages would have sent topping=onion&topping=bacon&topping=cheese. The same for maps, some libraries would format obj: { a: "b", c: 4 }, as obj[a]=b&obj[c]=4, others as obj.a=b&obj.c=4. It's not specified in an RFC anywhere, so there are a bunch of possible right solutions.

Though, as shown in https://github.com/loadimpact/k6/issues/878, k6 would currently do something that is definitely wrong... :disappointed: It would send something like topping=%5Bonion+bacon+cheese%5D&obj=map%5Ba%3Ab+c%3A4%5D, i.e. convert the complex types to their JS String() representation and send that. So maybe we should pick one of the conventions above and stick with it, even though it won't cover 100% of use cases? :man_shrugging: