Posted forms are decoded with ISO-8859-1 instead of UTF-8

[rreitmann]

Hi,

after upgrading from 1.3.0.M4 to 1.3.0.M5 form parameter if sent with a POST seem to be decoded with ISO-8859-1 instead of UTF-8. Have there been any changes?

[wilkinsona]

Not knowingly. Can you share a sample project that reproduces the problem?

[rreitmann]

Our project is public: https://github.com/dzhw/metadatamanagement

You can see the described behavior here https://metadatamanagement.cfapps.io/en/variables/create if you put an 'Ü' in label and submit the form.

[wilkinsona]

Thanks. And thanks, too, to @timtebeek.

Unfortunately, the changes made in 2b3d419 have altered the ordering of the auto-configured filters. In M4 the ordering was:

• Character encoding filter
• Hidden HTTP method filter and HTTP put content form filter

In M5 the ordering is:

• Hidden HTTP method filter
• HTTP put content form filter
• Character encoding filter

HiddenHttpMethodFilter accesses the request's parameters so it's vital that it go after CharacterEncodingFilter otherwise the parameters will be read in the wrong encoding.

A workaround is to declare your own OrderedCharacterEncodingFilter bean and ensure that it goes first:

@Autowired
private HttpEncodingProperties httpEncodingProperties;

@Bean
public OrderedCharacterEncodingFilter characterEncodingFilter() {
    OrderedCharacterEncodingFilter filter = new OrderedCharacterEncodingFilter();
    filter.setEncoding(this.httpEncodingProperties.getCharset().name());
    filter.setForceEncoding(this.httpEncodingProperties.isForce());
    filter.setOrder(Ordered.HIGHEST_PRECEDENCE);
    return filter;
}

[wilkinsona]

@dsyer I'm not sure of your motivations for moving OrderedCharacterEncodingFilter's order nearer to zero. Any objections to moving it back to HIGHEST_PRECEDENCE rather than just slightly before the other filters that we auto-configure?

[dsyer]

Don't think so.

[rreitmann]

Thanks for the immediate feedback. We will go with the workaround for the time being and upgrade to 1.3.0.RC1 as soon as it is available.

[lewinras]

but , why I meet the same problem like it in 1.5.8.RELEASE???

[wilkinsona]

@lewinras It’s impossible to say without more information. If you believe you’ve found a bug then please open a new issue with a minimal sample project that reproduces the problem.

[nargesfallahi]

@wilkinsona I was wondering if this bug still exists as I encountered it in my project. sending é in the GET request is decoded as é

[wilkinsona]

As far as we know, this bug is fixed. You haven't said which version you're using, but if you're on 2.0 then please be aware of #11607.

[Dmitrii-Iakovenko]

Good day. The problem is relevant again. Spring Boot 2.7.3 + Mustache. Solved by installing an encoder (not ordered).

But after adding Spring Security to the project, the order apparently changes, as described above.
In addition, the names of the Spring packages have changed.

This code works:

import org.springframework.boot.web.servlet.filter.OrderedCharacterEncodingFilter;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

import static org.springframework.core.Ordered.HIGHEST_PRECEDENCE;

@Configuration
public class FiltersUTF8Config {

    @Bean
    // https://github.com/spring-projects/spring-boot/issues/3912
    public OrderedCharacterEncodingFilter setUTF8OrderedCharacterEncodingFilter() {
        var filter = new OrderedCharacterEncodingFilter();
        filter.setEncoding("UTF-8");
        filter.setForceEncoding(true);
        filter.setOrder(HIGHEST_PRECEDENCE);
        return filter;
    }

}

[wilkinsona]

@Dmitrii-Iakovenko Can you please open a new issue with a minimal sample that reproduces your problem?