Micrometer: Adding micrometer influences characterEncodingFilter of Spring Boot

Created on 24 Aug 2018  路  2Comments  路  Source: micrometer-metrics/micrometer

I am using Spring Boot 1.5.14 with micrometer 1.0.5 via micrometer-spring-legacy with micrometer-registry-datadog.

I have noticed that without the micrometer dependencies, the characterEncodingFilter is the 2nd in the chain (after the metricsFilter which is one from Spring Boot itself):

2018-08-24 14:56:41.304  INFO 67181 --- [ost-startStop-1] o.s.b.w.servlet.FilterRegistrationBean   : Mapping filter: 'metricsFilter' to: [/*]
2018-08-24 14:56:41.305  INFO 67181 --- [ost-startStop-1] o.s.b.w.servlet.FilterRegistrationBean   : Mapping filter: 'characterEncodingFilter' to: [/*]

With this setup, I can set these properties in application.properties to force UTF-8 encoding:

# Charset of HTTP requests and responses. Added to the "Content-Type" header if not set explicitly.
spring.http.encoding.charset=UTF-8
# Enable http encoding support.
spring.http.encoding.enabled=true
# Force the encoding to the configured charset on HTTP requests and responses.
spring.http.encoding.force=true

This ensures that strings arrive in my @RestController in the proper encoding.

However, if I now add the micrometer dependency in my pom.xml, I see this order of filters:

2018-08-24 15:04:31.296  INFO 70178 --- [ost-startStop-1] o.s.b.w.servlet.FilterRegistrationBean   : Mapping filter: 'webMetricsFilter' to: [/*]
2018-08-24 15:04:31.296  INFO 70178 --- [ost-startStop-1] o.s.b.w.servlet.FilterRegistrationBean   : Mapping filter: 'metricsFilter' to: [/*]
2018-08-24 15:04:31.300  INFO 70178 --- [ost-startStop-1] o.s.b.w.servlet.FilterRegistrationBean   : Mapping filter: 'characterEncodingFilter' to: [/*]
2018-08-24 15:04:31.300  INFO 70178 --- [ost-startStop-1] o.s.b.w.servlet.FilterRegistrationBean   : Mapping filter: 'hiddenHttpMethodFilter' to: [/*]

So the micrometer webMetricsFilter comes first. As a result, the strings that arrive in my controller are no longer UTF-8 but iso-8859-1 (I checked this with the debugger).

The only way to work around it, is by no longer using the properties, but define the characterEncodingFilter manually in my own @Configuration class and give it the highest precedence:

    @Bean
    public FilterRegistrationBean characterEncodingFilter() {
        FilterRegistrationBean result = new FilterRegistrationBean();
        final CharacterEncodingFilter characterEncodingFilter = new CharacterEncodingFilter();
        characterEncodingFilter.setEncoding("UTF-8");
        characterEncodingFilter.setForceEncoding(true);
        result.setFilter(characterEncodingFilter);
        result.setOrder(Ordered.HIGHEST_PRECEDENCE);
        return result;
    }

By doing that, the characterEncodingFilter is first in the list of filters and the strings are proper UTF-8 strings again.

bug

Most helpful comment

@wimdeblauwe Thanks. It looks missed to be ported from Spring Boot 2.x support. I created #803 to fix this.

All 2 comments

@wimdeblauwe Thanks. It looks missed to be ported from Spring Boot 2.x support. I created #803 to fix this.

Fixed by #803. Thank you, @izeye

Was this page helpful?
0 / 5 - 0 ratings