Sorry if I'm missing something very basic. It's a bit tricky to confirm that it's not just something weird about my setup.

There are servers that default to other encodings like ISO_8859_1 for application/x-www-urlencoded. This, https://github.com/spring-projects/spring-framework/pull/31781, seems like a breaking change towards these.

I think this is the case for standard Spring boot Tomcat applications. The default is ISO_8859_1. So this could break some standard Spring to Spring integrations.

Seems tricky to solve this on the server end unless you're certain that nobody depends on the default being ISO_8859_1.

Could it be that the new behavior should be opt-in? I have not even found a way to opt-out.

Example:

This would in the previous version be decoded correctly as UTF-8 at the recipient. With the new version the UTF-8 encoded payload will get decoded using ISO_8859_1.

webClient.post()
                .uri("/submit")
                .header("Content-Type", APPLICATION_FORM_URLENCODED_VALUE + ";charset=UTF-8")

Comment From: jonkjenn

Was not able to reproduce in simpler situations so either we do something incompatible in the original project or it's a much more narrow issue.

Comment From: jonkjenn

We had a filter that ran before CharacterEncodingFilter that triggered parameter parsing. The change in behavior is still real for that situation as far as I can tell. I guess that falls more into the bucket of non default utf-8 edge-cases I'm sure was considered when making the change.

Comment From: flozano

you can replace MediaType.APPLICATION_FORM_URLENCODED with your own const declared as MediaType.parseMediaType("application/x-www-form-urlencoded;charset=UTF-8");