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?

Comment From: wilkinsona

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

Comment From: 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.

Comment From: wilkinsona

Thanks. And thanks, too, to @timtebeek.

Unfortunately, the changes made in https://github.com/spring-projects/spring-boot/commit/2b3d419e1023bf818443da55990e6c47c4b70016 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;
}

Comment From: 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?

Comment From: dsyer

Don't think so.

Comment From: 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.

Comment From: lewinras

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

Comment From: 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.

Comment From: 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 é

Comment From: 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 https://github.com/spring-projects/spring-boot/issues/11607.

Comment From: 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;
    }

}

Comment From: wilkinsona

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