Eureka Service Discovery is ignoring the Path part of the uri in the HttpClient base address

[sunnyverma01]

Describe the bug

Eureka service discovery omits the path from the hostname uri when replacing the service-name. It works fine when there is no path in the service uri but when there is, it ignores it and just uses the hostname part which forces me to add the path as part of the requestUri in the code.

Steps to reproduce

Steps to reproduce the behavior: I used the FortuneTellerUI and FortuneTellerService apps from the Steeltoe's samples to reproduce. (https://github.com/SteeltoeOSS/Samples/tree/main/Discovery/src) If I push the UI and Service apps as is, they work fine since they use random routes which means no path BUT if I modify the manifest.yml and add a route that has a path in it, it starts failing. Screenshots below:

Updated FortuneTellerService manifest.yml:

Service Registry:

FortuneTeller UI Logs:

In the above screenshot, its trying to do a GET http://fortune-api.net/api/fortunes/random instead of GET http://fortune-api.net/Service/api/fortunes/random

Expected behavior

If the registered uri of the service contains a path, the service discovery while replacing the service-name should not omit the path from the host name.

Environment (please complete the following information):

• Steeltoe Version [3.1.x]
• Platform: [Cloud Foundry)
• OS: [Linux]
• .NET Version [.NET Core 3.1.x, .NET 5, .NET 6]

Additional context or links

The changes that I made to the FortuneTeller UI and Service sample apps can be found here

[hananiel]

Hi @sunnyverma01 I looked into this and am somewhat mystified by the behavior. We are indeed using the GetHost() which should return the hostname of the instance - which from your logs is being returned correctly. See EurekaServiceInstance.cs I am wondering if cloudfoundry is returning multiple instances one for default route and other for the additional route. As a work around, are you able to adjust your client like:

  services.AddHttpClient("fortunes", c =>
                {
                    c.BaseAddress = new Uri("http://fortuneService/Service/api/fortunes/");
                })

[sunnyverma01]

Hey @hananiel, yeah, similar to that is what we ended up doing to make it work. We are adding the path as part of our relative url.

[TimHess]

This looks more like a feature request than a bug to me. Given the code, Steeltoe never attempted to support inclusion of a path in the service registry listings.

I don't see this as a high priority for the core team right now, but we can leave the issue open and anybody who wants it can upvote, chime in with more information and/or we can talk about a community PR to add this support

[TimHess]

Closing due to insufficient interest. If you would like to see this supported, please respond to this issue.