In v2.4.0-M2, behavior of server.servlet.encoding.force-response property has changed. Setting following properties results in Content-Type response header to include ;charset=UTF-8. Until v2.4.0-M1, content type used to honor produces configuration of @RequestMapping.
server.servlet.encoding.charset = UTF-8
server.servlet.encoding.force-response = true
Result
| Response Header | v2.4.0-M1 | v2.4.0-M2 |
|---|---|---|
| Content-Type | application/json | application/json;charset=UTF-8 |
I couldn't find any reference of this change in release notes, so assuming it's a bug. See sample MCVE : m2-demo.zip
Steps
Run mvn clean test.
Comment From: wilkinsona
Thanks for the sample, but it produces the same behaviour for me with both 2.4.0-M1 and M2 with the charset=UTF-8 being present in both cases. That's the behaviour that I would expect with Tomcat as it automatically appends the response's character encoding to the content type.
Comment From: kedar-joshi
but it produces the same behaviour for me with both 2.4.0-M1 and M2 ...
@wilkinsona Thanks for the reply but can you please check with mvn clean test ? I am able to reproduce this consistently.
Please see v2.4.0-M2.txt and v2.4.0-M1.txt.
That's the behaviour that I would expect with Tomcat as it automatically appends the response's character encoding to the content type.
I tried debugging the execution callflow but getContentType() isn't even called during this process. I will debug this further to see if I can provide a better explanation.
Comment From: wilkinsona
Thanks for adding some steps to the original description. I checked the behaviour by running the main method with M1 and M2 and it was the same in both cases. We can try again with MockMVC when we get a chance.
Comment From: wilkinsona
This rang a bell when I thought about it again. The change in behaviour is due to https://github.com/spring-projects/spring-framework/commit/5de549d7d4324c7e30ac607e15ebac444f8c3f28, which aligns MockMvc's behaviour with the Servlet spec and, therefore, with Tomcat.