Support being hosted on IIS sub application

[stamatiagk]

Expected Behavior / New Feature

Actual Behavior / Motivation for New Feature

It adds the application name to the downstream request uri

Steps to Reproduce the Problem

1. Desired downstream: localhost:8081/api.gatway/targeruri 1.Actual downastreamhost:port:/api.gateway/downloadtemplate

Specifications

• Version:
• Platform:
• Subsystem:

[TomPallister]

@stamatiagk please can you share your configuration json, program.cs / startup.cs so we can look into this further?

I don't understand your the issue you have raised :(

[stamatiagk]

Hi @TomPallister I noticed that when you a have an application under the default IIS site and you create a subapplication appA in www.xxx.com/appA/ it does not add the app basePath or respects the global BaseUrl :(

Also, it does not merge several config files. For example: var builder = new Microsoft.Extensions.Configuration.ConfigurationBuilder(); builder.SetBasePath(env.ContentRootPath) .AddJsonFile($"appsettings.json", optional: true, reloadOnChange: true) .AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true, reloadOnChange: true)
//.AddJsonFile($"configuration.test.{env.EnvironmentName}.json", optional: true, reloadOnChange: true)
.AddJsonFile($"configuration.test1l.{env.EnvironmentName}.json", optional: true, reloadOnChange: true)
.AddEnvironmentVariables();

[TomPallister]

@stamatiagk that is because this scenario is not supported. I don't think there is a way for Ocelot to know it is being hosted in an IIS sub application! I suggest just not hosting Ocelot like this :o there might be a way to support it but I don't know how.

[stamatiagk]

@TomPallister I was thinking of considering the BaseUrl or the PathBase when forming the upstreamhost variable maybe...

[TomPallister]

@stamatiagk do you know where I could see some documentation on how this works with IIS? I don't know much about this.

[stamatiagk]

@TomPallister maybe something on https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/iis/troubleshoot?view=aspnetcore-2.1 but I think the best way would be to consider the baseUrl on the upstream urls instead of the Host

[TomPallister]

@stamatiagk what is baseUrl? What object is it on? What does it represent? Will this break existing functionality? If you want to have a go at implementing this please do because I do not have time for new features at the moment...busy fixing bugs and dealing with questions! :(

[TomPallister]

I will set this issue to new feature and if I get time I will look at it but would be awesome if you could asses and make the changes to Ocelot!

[stamatiagk]

@TomPallister I will try and commit new code :)

[TomPallister]

awesome, let me know if you need any advice.

[raman-m]

@stamatiagk commented on Aug 31, 2018

What's your commit? What is the PR number?

[raman-m]

@stamatiagk Regarding IIS sub apps... They were introduced for users who don't know what is DNS names and domains for local hosting scenarios only! Why we need to implement a new BasePath feature to support only local host scenarios and only for IIS hosting? What is the benefit for such kind of rare cases?

As a team, we recommend to move to self-hosting aka Kestrel hosting and Docker containers. This is the best practice! Docker philosophy is based on ports & hosts! It is very useful on practice...

IIS is allowed for very experienced developers who don't use IIS sub-apps. Configure localhost DNS file with custom ports for localhost environment! For other environments like Staging and Production, you or your DevOps engineers must prepare domains for Ocelot and for all downstream services being deployed with domains.

Don't write a code! Just use IIS best practices with localhost DNS file. Good luck! 😉