Spring MappingJackson2HttpMessageConverter character encoding not propagated to the response

We add a Jackson message converter to our content negotiation manager, like this:

<bean class="org.springframework.http.converter.json.MappingJackson2HttpMessageConverter" c:objectMapper-ref="objectMapper" p:supportedMediaTypes="application/json" />

Recently we had to remove all references to APPLICATION_JSON_UTF8_VALUE (aka "application/json;charset=UTF-8") because it is removed in Spring 7.

When an endpoint has produces metadata without a charset parameter, like "application/json", the MappingJackson2HttpMessageConverter falls back to this method to determine the character encoding of the response:

    /**
     * Determine the JSON encoding to use for the given content type.
     * @param contentType the media type as requested by the caller
     * @return the JSON encoding to use (never {@code null})
     */
    protected JsonEncoding getJsonEncoding(@Nullable MediaType contentType) {
        if (contentType != null && contentType.getCharset() != null) {
            Charset charset = contentType.getCharset();
            JsonEncoding encoding = ENCODINGS.get(charset.name());
            if (encoding != null) {
                return encoding;
            }
        }
        return JsonEncoding.UTF8;
    }

The default (fallthrough) value is UTF-8. However, when this path is taken, no charset parameter is added to the Content-Type response header. Thus the caller may assume the HTTP default encoding of ISO-8859-1.

Workaround: set p:defaultCharset="UTF-8" on the message converter.

Is it possible to always add a charset parameter to the Content-Type response header within AbstractJackson2HttpMessageConverter?

This is Spring 6.2.13

see #19280 #14656

Comment From: bclozel

This is a conscious choice we made in https://github.com/spring-projects/spring-framework/issues/22788

If a client assumes ISO encoding for JSON, the client is definitively broken. We will not revert this change.

If your application needs to deal with clients not adhering to the spec, please consider setting up a custom Servlet filter that updates the content type response header for those cases.