Dynamic Routing Error: Using dynamic routing with services that use HTTP and HTTPS

[viktoralfa19]

Please I have a simple .Net 8 web api application where Ocelot version 23.2.2 is used and I have this configuration. I am also using CONSUL as service discovery.
When running in a container with docker-compose and trying to use dynamic routing I want to use internal APIs with HTTP and external APIs with HTTPS so I configure OCELOT like this:

{
  "Routes": [],
  "DynamicRoutes": [
    {
      "ServiceName": "openloyalti",
      "UseServiceDiscovery": true
    }
  ],
  "GlobalConfiguration": {
    "ServiceDiscoveryProvider": {
      "RequestIdKey": "OcRequestId",
      "Scheme": "http",
      "Host": "consul-server",
      "Port": 8500,
      "Type": "Consul"
    },
    "RateLimitOptions": {
      "ClientWhitelist": [],
      "EnableRateLimiting": false,
      "HttpStatusCode": 429,
      "QuotaExceededMessage": "Too many requests, please try again later."
    },
    "LoadBalancerOptions": {
      "Type": "LeastConnection"
    },
    "HttpHandlerOptions": {
      "UseTracing": true
    },
    "DownstreamScheme": "http"
  }
}

When doing so I always get this exception:

Basically I want to know how to solve my problem of using dynamic routing with services that use HTTP and other services that use HTTPS.

[viktoralfa19]

Something I forgot to mention is that the routes with HTTP are resolved successfully and if I want to make requests to the routes with HTTPS it returns an error and it is because the route resolution is HTTP and not HTTPS.

[raman-m]

Could you make the title shorter please?
It is very long!
Please focus our attention to the problem with short title.

Also, I'm confused in recognizing this issue as a bug or an question?

[raman-m]

@viktoralfa19 Are you online?

[raman-m]

When running in a container with docker-compose and trying to use dynamic routing I want to use internal APIs with HTTP and external APIs with HTTPS so I configure OCELOT like this:

Something I forgot to mention is that the routes with HTTP are resolved successfully and if I want to make requests to the routes with HTTPS it returns an error and it is because the route resolution is HTTP and not HTTPS.

Victor,
Based on your description you want to have the following DownstreamScheme property overriding in route config 👇

{
  "DynamicRoutes": [
    {
      "ServiceName": "openloyalti",
      "DownstreamScheme": "https" // important! It is HTTPS route
    }
  ],
  "GlobalConfiguration": {
    "ServiceDiscoveryProvider": {
      // ...
    },
    "RateLimitOptions": {
      // ...
    },
    // ...
    "DownstreamScheme": "http" // important! ALL routes are HTTP
  }
}

Am I correct?

🆗 This feature is not currently implemented in Ocelot! All dynamic routes should be HTTP or HTTPS globally, as defined in the GlobalConfiguration.DownstreamScheme option. Thus, the option is global and cannot be overridden at the route level within the DynamicRoutes collection.

Explanation of current design:

File-models

• FileGlobalConfiguration model has the DownstreamScheme property
  

  Ocelot/src/Ocelot/Configuration/File/FileGlobalConfiguration.cs

  Line 31 in 1b34be9

  public string DownstreamScheme { get; set; }

• FileDynamicRoute model has not the property at all!

Finally, global properties from FileGlobalConfiguration are utilized in all dynamic routes. However, the properties from FileDynamicRoute override those in FileGlobalConfiguration. Consequently, it is currently impossible to override the DownstreamScheme at the route level. This feature needs to be developed!
Are you going to contribute?

[raman-m]

Please I have a simple .Net 8 web api application where Ocelot version 23.2.2 is used and I have this configuration. I am also using CONSUL as service discovery.

Please upgrade to the latest stable version 23.4.3❗

Basically I want to know how to solve my problem of using dynamic routing with services that use HTTP and other services that use HTTPS.

As I have explained above, it is now impossible to override the scheme in route JSON via ocelot.json. If you really need this feature, a custom solution must be developed by writing C# code. Since the Consul provider is used, we can utilize either the Custom Provider or the Consul Service Builder features. The best option is the latter one due to the Consul provider.

🆗 To draft a solution, we need to override the GetServiceHostAndPort method:

Ocelot/src/Ocelot.Provider.Consul/DefaultConsulServiceBuilder.cs

Lines 91 to 94 in 1b34be9

	protected virtual ServiceHostAndPort GetServiceHostAndPort(ServiceEntry entry, Node node)
	=> new(
	GetDownstreamHost(entry, node),
	entry.Service.Port);

This method currently calls the constructor with two arguments:

Ocelot/src/Ocelot/Values/ServiceHostAndPort.cs

Lines 12 to 16 in 1b34be9

	public ServiceHostAndPort(string downstreamHost, int downstreamPort)
	{
	DownstreamHost = downstreamHost?.Trim('/');
	DownstreamPort = downstreamPort;
	}

To reapply the actual scheme, we must call the constructor with three arguments, including the scheme:

Ocelot/src/Ocelot/Values/ServiceHostAndPort.cs

Lines 18 to 19 in 1b34be9

	public ServiceHostAndPort(string downstreamHost, int downstreamPort, string scheme)
	: this(downstreamHost, downstreamPort) => Scheme = scheme;

The remaining task is to attach the new behavior class utilizing the AddConsul<T> method.

Which approach do you prefer: JSON or C#?

[viktoralfa19]

Finally, global properties from FileGlobalConfiguration are utilized in all dynamic routes. However, the properties from FileDynamicRoute override those in FileGlobalConfiguration. Consequently, it is currently impossible to override the DownstreamScheme at the route level. This feature needs to be developed! Are you going to contribute?

Thank you very much for answering quickly.

Of course nice to collaborate

[viktoralfa19]

I can't update to the current version 23.4.3 because I have another bug that I'm going to upload with a description

[viktoralfa19]

public ServiceHostAndPort(string downstreamHost, int downstreamPort, string scheme)
: this(downstreamHost, downstreamPort) => Scheme = scheme;
The remaining task is to attach the new behavior class utilizing the AddConsul method.

Which approach do you prefer: JSON or C#?

I would like to implement the modification made with C# code but it cannot be implemented by extending the functionality of the ocelot.consul library, or should it be changed in its source code?

[viktoralfa19]

@raman-m
Thank you very much, I actually updated to the latest version because this DefaultConsulServiceBuilder class does not exist with the version I was using and by modifying a couple of virtual methods I was able to use http and https with dynamic routing and the issue I had was still resolved. What I added was this class:

public class SchemaConsulServiceBuilder(
    IHttpContextAccessor contextAccessor,
    IConsulClientFactory clientFactory,
    IOcelotLoggerFactory loggerFactory)
    : DefaultConsulServiceBuilder(contextAccessor, clientFactory, loggerFactory)
{
    protected override string GetDownstreamHost(ServiceEntry entry, Node node)  => entry.Service.Address;
    
    protected override ServiceHostAndPort GetServiceHostAndPort(ServiceEntry entry, Node node)
    {
        if (entry.Service.Meta?.TryGetValue("Scheme", out var schema) ?? false)
            return new ServiceHostAndPort(GetDownstreamHost(entry, node), entry.Service.Port,
                schema);

        return new ServiceHostAndPort(GetDownstreamHost(entry, node), entry.Service.Port);
    }
}

And I used it here:

webApplicationBuilder.Services.AddOcelot(configuration).AddConsul<SchemaConsulServiceBuilder>();

I hope this helps someone else.

[raman-m]

I have a simple .Net 8 web api application where Ocelot version 23.2.2 is used
I actually updated to the latest version because this DefaultConsulServiceBuilder class does not exist with the version I was using

Indeed, the DefaultConsulServiceBuilder class has been available since version 23.3.0

What I added was this class:

    protected override ServiceHostAndPort GetServiceHostAndPort(ServiceEntry entry, Node node)
    {
        if (entry.Service.Meta?.TryGetValue("Scheme", out var schema) ?? false)
            return new(GetDownstreamHost(entry, node), entry.Service.Port,
                schema); // !!!

        return new(GetDownstreamHost(entry, node), entry.Service.Port);
    }

What is notable in your code is the extraction of the scheme value:

entry.Service.Meta?.TryGetValue("Scheme", out var schema)

This is the cornerstone of the logic. The agent service, known entry.Service.Address, lacks information about the scheme (protocol). Therefore, you read the scheme from Consul Meta-data.

Could you describe this use case in detail, please?
What are the ways to define scheme for service entry: metadata, tags?

I have an idea to work more on this case and possibly create a PR together with you.
It seems user scenario will be very useful for Consul & Ocelot fans.

[viktoralfa19]

Sorry @raman-m , due to time constraints I was not able to respond in time.

Regarding your use case question, the truth is very simple at least until now:

Could you describe this use case in detail, please? What are the ways to define scheme for service entry: metadata, tags?

Currently, together with my work team, we are developing a product based on microservices, where we need to centralize not only the APIs of our internal services but also components that provide services to us internally such as our own Identity Server or a CSM and also the APIs of external services. For clients, we coordinate actions between all these components, being completely agnostic to them. That is why the use of Consul as Service Discovery and as ApiGateway Ocelot work very well together, we are still in iterations of the solution, but we have reached the point that if we decide to use dynamic routing we will have the need to route from Ocelot to the endpoint that they use http which are our internal components and the external services which use https, hence the need to make a PoC to know if a scenario like this was feasible or not.

The definition we use when creating our external services within Consul is the following:

service = {
  id = "external-service"
  name = "external-service"
  tags = ["service"]
  Address = "external-service.com"
  Port = 443
  Meta = {
    "Scheme" = "https"
  }
  Check = {
    id = "external-service-check"
    HTTP = "https://external-service.com/api/healthcheck"
    name = "API software"
    interval = "10s"
    timeout = "5s"
  }
}

In this way we load the configuration of the external services in Consul when raising the container.

Obviously we didn't have the scheme before, but with the solution you gave me and analyzing in debug how the registry arrives from Consul, it occurred to me to send it as part of the Metadata of the registry.

I have an idea to work more on this case and possibly create a PR together with you. It seems user scenario will be very useful for Consul & Ocelot fans.

Well, for my part, I would be happy to listen to the proposal since I am interested in knowing more about Ocelot since it is going to be a component that will go by default in other projects that we have.

[raman-m]

@viktoralfa19 on Feb 3, 2025

Well, for my part, I would be happy to listen to the proposal since I am interested in knowing more about Ocelot since it is going to be a component that will go by default in other projects that we have.

Very well, Victor! I will propose something by opening a PR, but only after the .NET 9 release. My idea involves enhancing the existing DefaultConsulServiceBuilder class.

We have a similar feature in Kubernetes provider: Downstream Scheme vs Port Names.
This feature is based on named ports, so if the DownstreamScheme setting is defined, the appropriate named port will be chosen, and the exact scheme (protocol) will be applied.
What do you think about this feature?