Option to deactivate apiHost validation, to allow forwarding to localhost

We are using ReactorCloudFoundryClient to connect to the CF-API.

Version used:

    <dependency>
      <groupId>org.cloudfoundry</groupId>
      <artifactId>cloudfoundry-client-reactor</artifactId>
      <version>5.6.0.RELEASE</version>
    </dependency>

We provide this class with its connection context by building an instance of DefaultConnectionContext:

private DefaultConnectionContext getDefaultConnectionContext() {
    return DefaultConnectionContext.builder()
        .apiHost(config.getApiEndpoint())
        .build();
  }

As you can see, the builder reads the property apiHost from our app-config.

The CF-ApiEndpoint we want to connect to changes depending on the current target-environment. The application that implements ReactorCloudFoundryClient doesn't know about this environment though.
Instead, we send all http-traffic to a second, locally running application which knows about the current target environment.

For the above mentioned use-case, we have to set apiHost to localhost:4201, so the traffic is forwarded to our second, environment-aware application.

Using this setup, the following exception occurs upon building the DefaultConnectionContext instance:
IllegalArgumentException: "API hostname http://localhost:4201 is not correctly formatted (e.g. 'api.local.pcfdev.io')"

Looking at the call-stack, it seems like this method checkForValidApiHost() in AbstractRootProvider is causing the issue for us:

    @Check
    public final void checkForValidApiHost() {
        Matcher matcher = HOSTNAME_PATTERN.matcher(this.getApiHost());
        if (!matcher.matches()) {
            throw new IllegalArgumentException(String.format("API hostname %s is not correctly formatted (e.g. 'api.local.pcfdev.io')", this.getApiHost()));
        }
    }

We already considered multiple options to workaround this limitation in the apiHost-string-syntax, but so far we couldn't find any working solution sadly..
Do you guys maybe know a way to get around this validation-step of the apiHost property? Or is there any chance that we can disable this validation if needed, maybe through an additional building-param?

Thanks already for any help about this matter!

Commencez par AbstractRootProvider.checkForValidApiHost() et suivez la manière dont DefaultConnectionContext.builder() fournit apiHost. Déterminez comment rendre la validation facultative tout en préservant le comportement par défaut existant, puis vérifiez que localhost:4201 peut être accepté pour la transmission sans l’actuelle IllegalArgumentException.