-
Couldn't load subscription status.
- Fork 38.8k
Description
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, #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")