json content-type with charset not supported by some servers

[dillon-giacoppo]

Hello! I am using this to write a client for Artifactory. It looks like they do naive content-type parsing and do not accept charset=utf-8 in "application/json; charset=utf-8".

Section 6 of the application/json RFC states the media type has no optional or required parameters. Therefore whilst the Artifactory API might not be very robust, it is technically RFC compliant. The RFC also notes in section 3 that the charset of the json media type can be autodetected so there is not need to specify utf-8, utf-16, or utf-32.

Changing the media type to just application/json should in theory make the client compatible with more servers. There was an open issue with them to JFrog to add support for more robust parsing but it doesn't look like it has been touched in a few years https://www.jfrog.com/jira/browse/RTFACT-14981 and as mentioned before it is technically RFC compliant.

[jeevatkm]

@dillon-giacoppo Typically if you set the Content-Type header value in the request, Resty will not override user provided value.

// Same could be set at client level too
client.R().SetHeader("Content-Type", "application/json")

Can you please try and let me know?

[dillon-giacoppo]

I have already worked around the issue with a pre-request hook that converts the header if it exists so I don’t have to include it on every request. It does however seem from looking into this, that the shorter form will have better compatibility with servers that do naive string matching and is RFC compliant while adding the charset parameter is not, so it may be a worthwhile change regardless

[jeevatkm]

@dillon-giacoppo Okay, I will update the JSON content-type without charset in the next release.

[jeevatkm]

@dillon-giacoppo I have done changes in branch json-content-type-no-charset can you try it out and let me know?

[jeevatkm]

It has been merged to master and scheduled for next release v2.1.0.