The Wayback Machine - https://web.archive.org/web/20201129211329/https://github.com/loadimpact/k6/issues/1713
Skip to content

/ k6

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

samples html_form_post.js fails #1713

Open
stevenebutler opened this issue Nov 7, 2020 · 2 comments
Open

samples html_form_post.js fails #1713

stevenebutler opened this issue Nov 7, 2020 · 2 comments
Labels
bug good first issue
Milestone
v0.30.0

Comments

@stevenebutler
Copy link

@stevenebutler stevenebutler commented Nov 7, 2020

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
@stevenebutler stevenebutler added the bug label Nov 7, 2020
@na-- na-- added this to the v0.30.0 milestone Nov 9, 2020
@na--
Copy link
Member

@na-- na-- commented Nov 9, 2020

Thanks for reporting this, I'm not sure how nobody noticed we had a wrong example for 4 years... 😅
@na--
Copy link
Member

@na-- na-- commented Nov 9, 2020

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 #878, k6 would currently do something that is definitely wrong... 😞 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? 🤷‍♂️
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug good first issue
Projects
None yet
Milestone
v0.30.0
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
@na-- @stevenebutler
You can’t perform that action at this time.