Support wildcards in UpstreamHost as Nginx does

[davidni]

New Feature

Support routes that match wildcard sub-domains such as *.domain.example.com (and fix existing bugs in the process -- more on this below :))

Motivation for New Feature

ReRoute.UpstreamHost uses ordinal string comparison and does not support wildcards.

Implementation note

For reference, here's what Nginx supports (look under the Wildcard names section in particular). My suggestion that seems to align with Nginx ideas:

1. Parse the host header to extract the host and optional port. There is currently a bug in Ocelot where if the Host header is Host: example.com:123 it will not match a route with UpstreamHost example.com, which IMHO it obviously should
2. If there's a trailing dot in the incoming host name, remove it (i.e. example.com and example.com. should be treated the same)
3. UpstreamHost = "*.example.com" would be matched with regex ^[a-z0-9.-]+\.example\.com$
4. UpstreamHost = ".example.com" would be matched with regex ^(?:[a-z0-9.-]+\.)?example\.com$

(4) is nice because it is fairly common for a service to want to take over a domain and all of its subdomains, and it offers an easy way to do that with a single route.

I'll start working on this and will send a PR soon (maybe tomorrow). Let me know if you have any concerns or suggestions.

[TomPallister]

@davidni awesome this all sounds good to me, with PR lets just make sure there are tests for all the functionality you are going to add :D If you can be bothered updating the docs with all of this would also be awesome but I can do that if you dont want to! Really appreciate your contributions.

[davidni]

@TomPallister quick update since it's been a while. I haven't given up on this issue, but priorities changed a bit and I haven't been able to get to it. I still want to get to it asap, but there's other stuff on the way.

As a side note, I'm very happy with the 10.* release and that so many dependencies are gone. Makes it a lot easier for us to consume! Thanks and keep it up.

[TomPallister]

@davidni all good! I'm going to take out everything from Ocelot apart from FluentValidation and see where things are. I want to try and make the whole thing more extensible so people can spin up their own packages to get stuff done / maybe override Ocelot's default behaviour.

[rafaelcaviquioli]

I need wildcards to work with multiple staging environments

[raman-m]

Please show us your user scenario, not saying "I need". Any practical user scenarios with good description are welcome.

[raman-m]

@davidni commented on Jul 19, 2018:

I'll start working on this and will send a PR soon (maybe tomorrow). Let me know if you have any concerns or suggestions.

Hello Mr. David!
I would be happy if you let us know your plans on delivery a PR for review!
Do you have an intention to contribute?

Pay attention you've discussed 8th version with Tom, and nowadays we have 19th version for .NET 7.
A bit different product, right?
I guess your wildcard idea for upstream hosts is still actual.

---

@TomPallister
This is so nice! 🤣 5 years! 🎉
I believe the issue shows good idea. But user scenario is still unclear for me. I don't understand why we need to merge all subdomains into one super route definition. Would not it be risky?
It is dilemma:

• we have one super route which processes all subdomains traffic
• we will split and register multiple subdomains routes using dynamic routes feature in Service Discovery area

What do you think?

[raman-m]

Implementation note

For reference, here's what Nginx supports (look under the Wildcard names section in particular).

Why not to use just Nginx proxy with this functionality? 😉

---

My suggestion that seems to align with Nginx ideas:

Ah, got it... You had just idea... and nothing more! 🤣

[AlyHKafoury]

@raman-m Can I work on it ?

[raman-m]

@ggnaegi @RaynaldM

• Your opinion?
• Do we accept this functionality?
• Will this feature be useful for your production environments?

Please, pay attention this is Nginx feature cloning... 🤣

[raman-m]

@AlyHKafoury Dear Aly,
You should understand that nginx | Server names feature and Nginx has different philosophy than Ocelot one. Nginx functions as network traffic proxy (aka firewall with reverse proxy function), but Ocelot makes routing requests with deep protocol object transforms based on routes, for example in case of http(s) protos a HttpRequest obj is transformed deeply based on Route settings.
I'm worrying about mixing both philosophies.

[AlyHKafoury]

@raman-m I am sure you have more experience than me working with Ocelot and if that is your opinion, I can contribute to other areas that are more helpful to the project and the user-base.