Forward port of issue #25741 to 2.4.x.
Comment From: edwardsre
@wilkinsona This change has caused us some issues. We use a root URI with a scheme of locate:// for our internal service location. A request interceptor (first in the interceptor list) resolves the URI and wraps the request with the actual http URI. This change captures the root URI with the locate scheme in it.
When MetricsClientHttpRequestInterceptor calls DefaultRestTemplateExchangeTagsProvider to supply a uri tag value, the call to RestTemplateExchangeTags.uri(String urlTemplate) uses a regular expression looking explicitly for http or https. This regex does not match the captured URI, so we are seeing uri tag values like /locate://host/rest-of-uri....
Would it be feasible to alter the regular expression to not be specific to https? and match on any scheme? I would be happy to make the change and submit a PR. Or is there a better way to do this without using a request interceptor so that the locate is resolved to http or https before capturing the root URI?
Comment From: wilkinsona
Apologies for the unanticipated change in behaviour, @edwardsre. I guess you're referring to the changes in https://github.com/spring-projects/spring-boot/issues/25744 as this issue just added a test to verify that the fix for #25744 had fixed this problem as well.
I'm not too keen on changing the regular expression in RestTemplateExchangeTags. The scope of that change would be quite broad for a problem that feels quite specific. It might be possible for you to decorate the RestTemplates UriTemplateHandler with one that performs the locate:// resolution before delegating to the existing handler. This would have to be done after MetricsRestTemplateCustomizer which may present an ordering challenge. Alternatively, you could provide your own RestTemplateExchangeTagsProvider that strips the locate:// prefix from the URL before delegating to DefaultRestTemplateExchangeTagsProvider.