AbstractJackson2HttpMessageConverter - Check for encoding breaks JSON to POJO de-serialization experience

[kruegsch]

Affects: 5.2.7 (Spring Boot 2.3.1)

Due to a fix in Issue #25076
the AbstractJackson2HttpMessageConverter also blocks the out-of-the-box JSON to POJO de-serialization for responses with an encoding/character set not being unicode.

In our case a GET request to https://appleid.apple.com/auth/keys responses with a
Content-Type: application/json;charset=ISO-8859-1, which results now in
org.springframework.web.client.UnknownContentTypeException: Could not extract response: no suitable HttpMessageConverter found for response type [class x.y.z.AppleKeyRequest] and content type [application/json;charset=ISO-8859-1].

It would be nice to have an option to include non compliant JSON encodings for the given default converters or to have the encoding check as opt-in to be on par with previous default behavior.

[jhoeller]

@poutsma I suppose this also affects 5.1.16 since the same change got backported.

[poutsma]

@poutsma I suppose this also affects 5.1.16 since the same change got backported.

It does, yes.

[jeffjensen]

We were caught by this problem because we use
@RequestMapping(produces = MediaType.APPLICATION_JSON_VALUE)
because MediaType APPLICATION_JSON_UTF8 is deprecated.

Is there a better constant class to use?
Should we use the UTF8 one instead?
Is there something else to configure instead to comply with the stricter checking?

[poutsma]

@jeffjensen This issue should only occur when dealing with non-unicode JSON. By default (i.e. without a charset specified in the Content-Type) JSON is UTF-8 encoded. It was only because of a bug in Chrome that the explicit UTF-8 parameter was required. That bug is now fixed, and that is why we deprecated the constant.

Can you elaborate more about your setup? Is your service producing non-unicode JSON?