Hi @matthewlowry, thanks for the PR!

Give me a couple of days to work through this. I just went back and looked at other encoding issues (which now have their own label!) and want to make sure this is the best choice, especially considering backwards compatibility for all users.

I think it would be awesome to add a config option to enforce RFC3986 or not, so that both use cases are handled.

(also applies to #1671, and some other related issues/prs tagged 'encoding')

I think it would be awesome to add a config option to enforce RFC3986 or not, so that both use cases are handled.

Totally. This PR is basically just the quick and dirty hack I did to get my company's app working again. If I get some free time I'll try to whip up something better.

Hi,

what is the status here? IMO the encoding of the "key" is just wrong

This PR with #1565 allow to have a behavior similar to qs natively.

Hi,

What work is still required for this PR to be merged?

I am currently unable to use this library at work as we need to have a param value containing square brackets []. Our tomcat server rejects the request because the correct encoding of the characters is removed.

If I submit a PR with a config option to enable/disable RFC3986 compliance, would it be easier to merge

On this I don't think this should be implement as mentioned previously if you'd like to use another format, you can set a custom paramsSerializer as follows:

axios.defaults.paramsSerializer: function(params) {
  // return a query string
}

Using the qs library:

axios.defaults.paramsSerializer: function(params) {
  return qs.stringify(params, { indices: false }); // param=value1&param=value2
}