Spring Cloud Config HttpClientConfigurableHttpConnectionFactory::getUrlWithPlaceholders incorrect behavior when hostname contains placeholder value

Describe the bug Version: 2022.0.2

Observed behavior: we are moving our repositories to a different bitbucket server. This new bitbucket server is behind a proxy while the old one was not. We've noticed that requests for specific configurations result in http failures when the config-server is trying to access the repo.

Analysis: We have a git url configured like this:

uri: 'https://foo.bar.com/config/{application}-config.git'

Now, when requesting a config for an application named bar, the HttpClientConfigurableHttpConnectionFactory will fail to find a builder, resulting in execution of the else branch here: https://github.com/spring-cloud/spring-cloud-config/blob/0a3636720840f4b2a88c5fcf07d62c457326e8a9/spring-cloud-config-server/src/main/java/org/springframework/cloud/config/server/environment/HttpClientConfigurableHttpConnectionFactory.java#L71-L82 This, in turn, will not use proxy settings, which in our scenario will result in failed http calls to the repo.

It looks like the failure to resolve the HttpClientBuilder is due to the logic in getUrlWithPlaceholders here: https://github.com/spring-cloud/spring-cloud-config/blob/0a3636720840f4b2a88c5fcf07d62c457326e8a9/spring-cloud-config-server/src/main/java/org/springframework/cloud/config/server/environment/HttpClientConfigurableHttpConnectionFactory.java#L134-L149 In this scenario, this will return a spec like https://foo.{application}.com/config/{application}-config.git, because spec.replace(...) will replace every occurrence.

Any suggestions for a workaround?

Comment From: tschut

I've found a workaround for the issue: by using pattern matching in the configuration I can "force" the right url. Following the earlier example, the config with workaround:

uri: 'https://foo.bar.com/config/{application}-config.git'
repos:
  bar-workaround:
    pattern: bar/*
    uri: 'https://foo.bar.com/config/bar-config.git'

This will introduce another HttpClientBuilder which doesn't have placeholders, so it will be a direct match and the correct builder will be used.

It's pretty fragile as the users of this configserver deployment could at any time introduce a new repository which will trigger this bug again, but for now I'm unblocked.