Undocumented change to body-less POST request Content-Type?

[dylanscott]

#### Summary

I've noticed a change in the behavior of body-less POST requests sent from axios between v0.16.1 and v0.17.1. This change is breaking and as far as I can tell it is not documented.

Here is some code that exercises this:

var axios = require('axios')j

axios.request({
  method: 'POST',
  url: 'https://api.dropboxapi.com/2/users/get_current_account',
  headers: {
    Authorization: 'Bearer <REDACTED>',
  },
})
.then(({ data }) => {
  console.log('data', data)
}, (err) => {
  console.error('err', err)
})

I've ran this request through a proxy that records the request details. For v0.16.1 I get:

POST /2/users/get_current_account

accept: application/json, text/plain, * / *
authorization: Bearer <REDACTED>
user-agent: axios/0.16.1
host: api.dropboxapi.com
connection: close
content-length: 0

For v0.17.1:

POST /2/users/get_current_account

accept: application/json, text/plain, * / *
content-type: application/x-www-form-urlencoded
authorization: Bearer <REDACTED>
user-agent: axios/0.17.1
host: api.dropboxapi.com
connection: close
content-length: 0

Note that now a default Content-Type header is being specified, even though there is no request body. This breaks in particular on this Dropbox API endpoint I'm hitting because it requires you not to specify a Content-Type header. The only way I've figured out how to not send this header is to add a request interceptor that deletes it, which is pretty annoying.

#### Context

• axios version: v0.17.1
• Environment: node v6.9.5

[dylanscott]

Looking into this further, it looks like this was a change between v0.16.1 and v0.16.2, and in fact is a consequence of #930. Changing the method in the code sample to "post" results in the same header being included on v0.16.1

I'm not really sure whether to call this a breaking change, so I will defer to you on that. Presumably technically the code above was considered incorrect pre-0.16.2 because it specified method: POST. But the code still resulted in the correct POST request being sent, even though it stopped the default content-type header from being included, so it was confusing and seemed breaking if you depended on that bug (as I was)

[vouill]

I did encounter a bug related to it. When using a transform request in POST request, the Content-type header automatically sets to application/x-www-form-urlencoded, even if we correctly re set the header in the transform request callback. i had to fallback on 16.0

[ablankenship10]

This also breaks PUT when uploading to a presigned S3 URL, since the URL I'm uploading to is signed with an API secret key, the request made to it needs to look exactly as expected.

[riyasdeen]

@dylanscott - Thanks for the interceptor tip, even though not pretty gets it working.

If it helps someone, here's the code.
Axios.interceptors.request.use(function (config) { if (config.url === "https://api.dropboxapi.com/2/users/get_current_account") { delete config.headers.post["Content-Type"] } return config; }, function (error) { return Promise.reject(error); });

[Alanscut]

this PR #372 has solved this problem，Please migrate to version 0.18.0 or 0.19.0.