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");