Ordering of `WebMvcMetricsFilter` breaks character encoding

Actuator’s WebMvcMetricsFilter has a hard-coded order of Ordered.HIGHEST_PRECEDENCE, which in practice puts it ahead of CharacterEncodingFilter. Since WebMvcMetricsFilter performs the mapping introspection, under some circumstances it will touch the POST data hence breaking the CharacterEncodingFilter.

I’ve managed to put together a sample app that exhibits this behavior with a specific set of request mapping paths. After starting the app, issue the following HTTP POST request (samples use HTTPie):

$ http -f POST :8080/pv/post name='Vedran Pavić' Content-Type:'application/x-www-form-urlencoded'
HTTP/1.1 200 
Content-Length: 21
Content-Type: text/plain;charset=UTF-8
Date: Thu, 11 Jan 2018 17:58:44 GMT

Hello Vedran Pavić

When spring-boot-starter-actuator is removed from the dependencies, which gets WebMvcMetricsFilter out of the picture, request is processed as expected:

$ http -f POST :8080/pv/post name='Vedran Pavić' Content-Type:'application/x-www-form-urlencoded'
HTTP/1.1 200 
Content-Length: 19
Content-Type: text/plain;charset=UTF-8
Date: Thu, 11 Jan 2018 17:59:32 GMT

Hello Vedran Pavić

[vpavic]

Remove @GetMapping which use parameter based mapping, then post will work fine or remove the path variable from post then it will work fine.

I wouldn’t call this a workaround as it requires you to drop the handler mapping that’s perfectly valid. The actual workaround that’s viable would involve, as you initially suggested, extending the CharacterEncodingFilter to implement PriorityOrdered and replace the OrderedCharacterEncodingFilter provided by Boot.

That being said, I’m not sure Boot should make implementing PriorityOrdered a permanent fix as it sounds a bit extreme measure for a web filter (are there any web filters implementing PriorityOrdered across the Spring projects?). Additionally, if for some reason users really do want to get something in front of CharacterEncodingFilter that would be a potential problem for them. And like with the current situation, if in the future there is some other framework provided filter that also implements PriorityOrdered with the same order we’d have the same situation (that’s why IMO web filter implementing PriorityOrdered is a dangerous precedent).

IMO Boot should consider having a well defined (and tested) order of web filters it provides/configures which would make it easier both for Boot itself and users to add new filters to the mix as the results would be predictable.

[sriki77]

Should the CharacterEncodingFilter be made to implement PriorityOrdered with highest precedence?