WebMvcTags always reports "root" as uri when servlet Filter handles the request

[jkuipers]

This in relation to #13064 (comment), where Phil asked me to create a new issue.

In a Spring-MVC Boot app, http.server.requests metrics are always reported with a root uri if the request, which would be mapped to Spring-MVC controller under normal circumstances, is handled by a servlet Filter instead. This happens for example when using Spring Security.
The reason is that the WebMvcTags uses the path info of the request in these situations, which is always null because the DispatcherServlet is mapped as a default servlet: the whole path is then present in the servlet path instead.

I would suggest to revisit the class to use the servlet path instead to have more reliable metrics. Per Phil's request I've attached a simple project to demonstrate the current behavior.
root-uri-demo.zip

[philwebb]

We're not sure that we can use the servlet path because it's going to cause an explosion of metrics. We'll investigate other options.

[bclozel]

The team has discussed this again, and we don't think we can address that problem.

• as explained, taking the servlet path from the request would create an explosion of metrics
• other paths (like a Filter mapping path) won't be useful
• we won't call in the MVC infrastructure to map that request, as it creates security concerns and can be quite involved (CORS support, interceptors)

Also, getting the Controller mapping would not really help. If a request is really slow and the Filter processing the request is at fault, we would report the Controller path pattern and confuse developers about the misbehaving parts of their applications. Maybe the Servlet filter name would be more useful here, but there's no way to get that in the filter chain, and that information would not really map to a uri tag.

As a result, we're closing this issue.