Character encoding is reset when exceptions are handled in MVC

[a96219]

When a global exception is caught via @RestControllerAdvice and a ResponseEntity is returned,
HttpServletResponse.getCharacterEncoding() returns UTF-8 in Spring Boot 3,
but returns ISO-8859-1 in Spring Boot 4.

springboot 3 config:

server:
  servlet:
    encoding:
      charset: utf-8
      enabled: true
      force-response: true

springboot4 config:

spring:
  servlet:
    encoding:
      charset: utf-8
      enabled: true
      force-response: true

Minimal example program:

• Minimal example program for Spring Boot 3: spring-boot-3
• Minimal example program for Spring Boot 4: spring-boot-4

Steps to run:

1. Start the Spring Boot application by running the com.lwd.Main.main() method
2. Access the endpoint http://127.0.0.1:8080/test

In Spring Boot 3, the following log can be seen in the console:

2026-01-14T02:03:10.342+08:00  INFO 137476 --- [nio-8080-exec-1] com.lwd.LogFilter                        : charSet:UTF-8

In Spring Boot 4, the following log can be seen in the console:

2026-01-14T02:03:38.296+08:00  INFO 118412 --- [nio-8080-exec-2] com.lwd.LogFilter                        : charSet:ISO-8859-1

[philwebb]

It looks like apache/tomcat@86a60a1 has changed the way that Tomcat works and when Spring calls response.setHeader(HttpHeaders.CONTENT_TYPE, null) the result is that org.apache.catalina.connector.Response.setContentType(String) is called with null and the character encoding is cleared.

I'm not sure if this is a Tomcat issue or a Spring Framework issue. @markt-asf may be able to help if it's a Tomcat issue, otherwise @bclozel can transfer this to the Spring Framework issue tracker.

[markt-asf]

That change in Tomcat was a specification mandated one so it is extremely unlikely to be changed in Tomcat. This looks like an issue for Spring Framework to me.

[bclozel]

I'm not sure what the best course of action is here. At least, I don't think Tomcat should change its behavior.

I think this is a combination of several things:

• Spring Framework resets content headers when handling errors (see Content-Type response header duplicated for failed StreamingResponseBody return value #34366), because error handling needs to perform content negotiation again and adapt to how the error is handled
• Tomcat clears the charset encoding from the response when the content type response header is removed
• the CharacterEncodingFilter applies the charset before the request is processed by the Servlet; by the time error handling is applied, this information is gone and is not re-applied

We could consider getting the charset information before removing content headers and re-applying it as part of error handling, but I'm not sure it's actually right. In this sample, the response should be UTF-8 anyway because JSON will not be using the ISO encoding.

[rstoyanchev]

@markt-asf granted the change is mandated to match the Servlet spec, what is the best way to do what we need to do? Here is a brief summary of the case.

The applications is processing the request, sets the content type, perhaps even starts writing to the response, but the response is not yet committed when it runs into an exception. The exception is handled by the application through a dedicated exception handling method that's invoked by Spring MVC, but prior to invoking it, it needs to reset the content type in order to allow content negotiation for an error response that's independent from the main request handling (e.g. application/json vs application/problem+json).

The reset of the content type should ideally preserve the character encoding, which has been set independently, and earlier through a global filter. Either restoring a previous value or leaving it not set.

I guess we can get the characterEncoding from the response, but that seems to return a default value if not set. We would rather avoid setting it explicitly to such a default value as that may also cause side effects.

[markt-asf]

Hmm. I can think of a few Tomcat specific ways to do that but those solutions are fragile and don't help the general case. Can you re-use the logic from the global filter to set (or not) the character encoding for the error response?

[rstoyanchev]

The the contentType is reset in the Servlet (DispatcherServlet), which is not aware of the Filters in front of it. Also, it's possible for the characterEncoding to be set by a custom filter, or by any other code during request handling. So, not really.

[markt-asf]

Just thinking about options. How would you want the following scenario to work:

• response has default encoding
• global filter calls setCharacterEncodoing("encodingA")
• application calls setContentType("something;charset=encodingB")
• error occurs
• response is reset
• encoding is now?

[rstoyanchev]

That's a good question to consider as the encoding might have been set more locally as part of request handling.

One thought is, we could remember what the encoding was at the start of DispatcherServlet processing, and then use the saved value in case of a reset as part of error handling.

That still leaves the question if the saved value was explicitly set or is just a fallback, but arguably no other code can check the same, so maybe it's okay if we explicitly set it to the default value.