StringHttpMessageConverter lost a fix that assumed charset UTF-8 for "application/json"

[iorjfeiofjseoirf]

With #22100 (release 5.1.4) the StringHttpMessageConverter used charset UTF-8 for application/json, which is correct. However, the change to StringHttpMessageConverter.java was undone with #22954 (release 5.2.0).
#22954 aims to remove the charset parameter from Spring MVC JSON content type. But the lines dropped from StringHttpMessageConverter.java do not add a charset parameter to a content type. Instead they define the charset which will be used in interpreting messages. Without the fix from #22100 the charset for JSON messages defaults to ISO_8859_1, which is not correct and would require to set the charset explicitly.

[rstoyanchev]

That seems like a regression indeed. I can't see why bc205e0 dropped the charset defaulting to UTF-8 for JSON in StringHttpMessgageConverter. That isn't actually added to a header. @sdeleuze do you agree?

[rstoyanchev]

Tentatively scheduled for 5.2.3.

[sdeleuze]

@rstoyanchev For the reading side, I agree and this is confirmed by an additional StringHttpMessageConverterTests#readJSON test I wrote. But while writing a StringHttpMessageConverterTests#writeJSON one, I figured out that we need potentially to take care about the writing side as well, since currently I think application/json is processed as application/json;charset=ISO-8859-1 due to the fact that StringHttpMessageConverter default charset is StandardCharsets.ISO_8859_1. And if we modify something here, we need to make sure the resulting content type header is application/json not application/json;charset=UTF-8 (implicit UTF-8 encoding).

Any thoughts?

[rstoyanchev]

Indeed, that should be the outcome. I'll add such tests and ensure they pass. Probably getDefaultCharset() could be overridden to return null for application/json if the default hasn't been set explicitly (i.e. is same as DEFAULT_CHARSET).