Form content-type lost the charset somewhere >2.40.0

[jkrems]

Headers using request@2.40.0:

{ 'content-type': 'application/x-www-form-urlencoded; charset=utf-8',
  'content-length': '14' }

Headers using request@2.57.0:

{ 'content-type': 'application/x-www-form-urlencoded',
  'content-length': '14' }

This causes problems with services that default to a different charset.

[jkrems]

Guess this was caused by #1159. Confused why some stacks are apparently not affected by this since it does look like the form parameters are encoded as utf-8. So a decoder on the other side trying to read it as something else should break afaict.

[jkrems]

Would it be acceptable to have an option (e.g. forceFormEncoding: true) to restore the old behavior? Or at least honor existing content-type headers in req.form(x)? If so, I'd be happy to create a PR. :)

[simov]

Request should honor any user defined header. According to this #701 (comment) it seems that this was working back then, but I just tested and it's not, so probably something changed along the way. I'm going to investigate that. As for forceFormEncoding option, I don't think that would be necessary if the content-header can be overriden by the user (like it should).

[jkrems]

Sounds good! For clarity: We are currently using a delayed setHeader in gofer to restore the old behavior. But it would be great if options.headers['content-type'] would work as well (since the current workaround code looks pretty ugly).

[simov]

@jkrems just pushed the fix #1650 also I just noticed that the example here #701 (comment) is using body instead of form.

[jkrems]

@simov Thanks for the update! :)