Content-type header for application/json should not contain charset field, according do RFC 8259

[OJezu]

Describe the bug
According to RFC 8259 - The JavaScript Object Notation (JSON) Data Interchange Format content-type application/json does not have any charset defined, as it must be utf-8 encoded. Older specifications allowed other unicode encodings, and parsers were detecting exact encoding used by first four bytes, still not by charset param.

Axios defaults to header Content-Type: application/json;charset=utf-8 for some types of sent data.

This breaks some HTTP servers and applications, who are not recognizing the content-type.

To Reproduce

axios.post("http://example.com", {an: "object"});
// Content-Type: application/json;charset=utf-8 header will be set

Expected behavior
Content-Type: application/json header should be set as default for object data, without charset parameter.

Environment:

• Axios Version - 0.18.0, I've also checked master branch source - it is still there.
  

  axios/lib/defaults.js

  Line 52 in b4c5d35

  setContentTypeIfUnset(headers, 'application/json;charset=utf-8');

Additional context/Screenshots
This breaks some parts of the rabbitmq-management API.

Related issues:
#859

[mpark86]

Is there any update on this issue? I'd like to try creating a PR for this.

[chinesedfan]

See #2603 (comment). Thanks for @mpark86' pull request anyway.

And if you don't like it, you can replace it easily by configuring transformRequest.

[OJezu]

@chinesedfan just Ctrl+F the RFC referenced in that comment and in this issue.

Note: No "charset" parameter is defined for this registration.
Adding one really has no effect on compliant recipients.

o Added a note to the "IANA Considerations" clarifying the absence
of a "charset" parameter for the application/json media type.

[chinesedfan]

@OJezu I am not sure I get what you means. I guess you are proving your point. According to RFC 8259, the charset is not required and some servers are not supported to parse it.

Never mind, at least MDN includes the charset. More servers work well with it. And as I said, if you don't like it, you can replace it easily by configuring transformRequest. Thanks for understanding.

[OJezu]

@chinesedfan what I'm proving, is that application/json type does not have "charset" defined. Providing it is non-standard, no matter what the servers do with it.

Axios is behaving in a way not specified in standard, and this is what the issue is about. Common errors alone in other software are not a reason to break RFC.

[chinesedfan]

@OJezu After read more carefully, I think they are 2 things.

• You mentioned RFC 8259, which requires JSON should be UTF-8 encoded. And media type should be application/json.
• And I pasted a MDN link, which includes RFC 7231.

Content-Type is defined in RFC 7231, instead of RFC 8259. And its format is media-type charset boundary. So axios doesn't break any BFCs.

[OJezu]

@chinesedfan where in RFC7231 is charset parameter defined for application/json? It's not, because parameter names are defined for concrete media-types in appropriate RFCs. charset parameter is neither declared for all headers nor for all media-types. application/json media-type does not have "charset" parameter defined.

From RFC7231

The presence or absence of a
parameter might be significant to the processing of a media-type,
depending on its definition within the media type registry.

See IANA media type registry for application/json:
https://www.iana.org/assignments/media-types/application/json

And compare to plain/html entry which has charset parameter explicitly defined:
https://www.iana.org/assignments/media-types/text/html

[chinesedfan]

@OJezu I see. Now you have persuaded me. application/json is different with other media types.

[alexandr2110pro]

Any progress on that?

[OJezu]

There was a pull request done #2603, but @mpark86 did not change the expected header in tests, so they are failing. Until somebody fixes tests I expect no progress. I switched to node-fetch, so I lost interest anyway. If you can't switch out, tough luck, I suggest fixing the PR and hoping someone will merge and release.

[jasonsaayman]

We should try mend this in 0.20.0 I will look at the pull request.