Skip to content
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

Overwrite request header "application/x-www-form-urlencoded", when none is specified #1865

Closed
thim81 opened this issue Feb 18, 2021 · 1 comment
Labels

Comments

@thim81
Copy link

thim81 commented Feb 18, 2021

The K6 requests always seems to fallback to the request header "application/x-www-form-urlencoded", when none is specified. This is the default behavior of k6, as described in https://k6.io/docs/javascript-api/k6-http/post-url-body-params.

This is not ideal, when your API requests a specific content-type, which would mean that the content-type has to be set on all http.res functions. This is not ideal when having large K6 test sets.

Feature Description

A Provide the option to define/overwrite the request header with another another default, for when none is specified.

Suggested Solution (optional)

Allow the definition of default request headers in the "option".

Example

export let options = {
    vus: 5,
    stages: [
        { duration: "3m", target: 10 },
        { duration: "5m", target: 10 },
        { duration: "10m", target: 35 },
        { duration: "1m30s", target: 0 },
    ],
request-headers: [
"Content-Type": "application/json"
]
};
export default function () {
  // our HTTP request, note that we are saving the response to res, which can be accessed later
  const res = http.get('http://test.k6.io');
  sleep(1);
  const checkRes = check(res, {
    'status is 200': (r) => r.status === 200,
    'response body': (r) => r.body.indexOf('Feel free to browse') !== -1,
  });
}

@na--
Copy link
Member

na-- commented Feb 19, 2021

Thanks for making this issue! I think it can be classified as a sub-set of #761, so I'll close this one in favor of it.

Take a look at the comment I left there today (#761 (comment)) with some workarounds for the issue you're having, until we get around to fixing it properly.

@na-- na-- closed this as completed Feb 19, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants