Ignore trailing slash by default when recording web metrics

[rswart]

The WebMvcMetricsFilter uses the HandlerMapping.BEST_MATCHING_HANDLER_ATTRIBUTE to determine which handler the metric should be labeled with.

Since useTrailingSlashMatch is true by default most mvc controllers configured with a request mapping like:

@GetMapping(path = "/foo", produces = {MediaType.APPLICATION_JSON_VALUE})

will match both /foo and /foo/ and as a result BEST_MATCHING_HANDLER_ATTRIBUTE for this request mapping can have 2 values.

This leads to split metrics for the same request mapping: one for /foo and one for /foo/.

For now I have worked around this with a MeterRegistryCustomizer that strips the trailing slash, but I wonder if this does not deserve a more structural solution, e.g inside the metrics filter itself.

[philwebb]

@rswart Thanks for the report. I've transferred this issue to the Spring Framework team to see if they can deal with this when setting the BEST_MATCHING_HANDLER_ATTRIBUTE value. I think that might be the best solution since it will fix any other applications that rely on the attribute.

[rstoyanchev]

will match both /foo and /foo/ and as a result BEST_MATCHING_HANDLER_ATTRIBUTE for this request mapping can have 2 values

I'm probably missing something. The attribute reflects the matched handler. Shouldn't that be the same in both cases?

[philwebb]

@rswart Did you mean HandlerMapping.BEST_MATCHING_PATTERN_ATTRIBUTE? I think that's the attribute that we use to add the uri tag. See WebMvcTags.

[rswart]

Yes, apologies. I didn't look into it deeply enough.

So apparently 2 patterns are created for the same handler when useTrailingSlashMatch is true leading to 2 separate metrics in micrometer.

[rstoyanchev]

The BEST_MATCHING_HANDLER_ATTRIBUTE correctly reflects the pattern used to match the handler. There is no promise that it will present a unique value that is insensitive to trailing slashes.

I am quite certain that what is a "fix" for some will cause regression for others. A valid counter-argument would be that it's better to present the complete information, and the trailing slash can then be easily filtered out or ignored. I think it would make more sense for a metrics filter to decide whether to strip trailing slashes or not, possibly making that configurable.

[rstoyanchev]

I am closing this from a Spring Framework perspective, but feel free to re-open and transfer back to Spring Boot if that makes sense.

[bclozel]

The team decided to strip trailing slashes in our metrics filter, but still offer a configuration property in case trailing slashes are meaningful for some applications.