#360 Routing based on request header

[jlukawska]

Closes #360

• Routing based on Request Header #360

Proposed Changes

Additionally to routing by UpstreamPathTemplate, you can define UpstreamHeaderTemplates. Then to match a route, all the headers from this section must exist in the request headers.

The example:

    {
        "DownstreamPathTemplate": "/",
        "DownstreamScheme": "https",
        "DownstreamHostAndPorts": [
                { "Host": "10.0.10.1", "Port": 80 }
            ],
        "UpstreamPathTemplate": "/",
        "UpstreamHttpMethod": [ "Get" ],
        "UpstreamHeaderTemplates": {
            "country": "uk",
            "version": "v1"
        }
    }

In this case the route will be matched only if a request has both headers set to the configured values.

You can use placeholders in your UpstreamHeaderTemplates in the following way:

    {
        "DownstreamPathTemplate": "/{versionnumber}/api",
        "DownstreamScheme": "https",
        "DownstreamHostAndPorts": [
                { "Host": "10.0.10.1", "Port": 80 }
            ],
        "UpstreamPathTemplate": "/api",
        "UpstreamHttpMethod": [ "Get" ],
        "UpstreamHeaderTemplates": {
            "version": "{header:versionnumber}"
        }
    }

In this case the whole value for the request header version will be placed into the DownstreamPathTemplate. If you need, you can specify more complex upstream header template with placeholders like e.g. version-{header:version}_country-{header:country}.

Placeholders do not have to exist in DownstreamPathTemplate. This case may be used to require specific header no matter what the value it contains.

UpstreamHeaderTemplates section can be used also for Aggregates.

[Thanos06660]

Looks good with one little comment ;)

[fadil-khodabuccus-cko]

Hi @Thanos06660 @jlukawska,

Thanks for this PR! This is something super useful :)

Do we know if this is going to be released soon?

Best,
Fadil

[CorporateActionMan]

@fadil-khodabuccus-cko commented on Apr 8, 2021

I agree this is super useful and should be released

[stodolos]

Vote up! Any word on when this will be released?

[madebykrol]

Hello.

Just wanted to check in to see if there is any progress to release this?

[akanmf]

Hi @jlukawska, Any news ?

[felipepiresdejesus]

Hi, please accept it. We are really needing this feature and this is opened since 2020

[jlukawska]

Hi @jlukawska, Any news ?

Unfortunately, I don't have rights to merge it. It seems that the Ocelot project has been abandoned by its owner :(

[raman-m]

@felipepiresdejesus commented on Apr 13, 2023:

Hi, please accept it. We are really needing this feature and this is opened since 2020

Don't worry, Felipe! 😊
Coming soon... 😎

Will you resolve all merge conflicts? 😉
It is a joke!

[raman-m]

Well... @jlukawska

Before resolving merge conflicts for this PR, could we work on develop branch in your fork, please?
After merging PR 7 your repo has redundant merge commit. That was happen because you used "Merge commit" option while merging the PR. For canonic updates it is better to use fast-forwarding option (rebase).

Step 1

To fix that you need to remove current top-commit which is merge commit (it has 2 parents). Use this command:

git checkout develop
git reset --hard HEAD~1

Reset command will report: HEAD is now at 0af49617 Merge pull request #2 from ThreeMammals/develop

After that, try to Sync fork please?
I hope it should help you to make canonic update of develop branch. I hope Sync Fork operation will apply rebasing.

Step 2

Because you have other merge commits in develop branch which don't belong to head repository, I expect Sync Fork will fail because of some reason. In this case it is better just to remove develop branch, and provide new Sync Fork to pull develop branch entirely.

Step 3

If step 2 failed (no the same top commit in develop), just delete develop branch using GitHub UI and make git fetch --all, and remove develop locally.
After that use this script to pull develop from head (upstream) repository:

git remote add upstream https://github.com/ThreeMammals/Ocelot.git // add original repo as upstream remote
git fetch upstream                                                 // pull changes from original repo
git checkout -b develop upstream/develop                           // pull down develop branch locally
git push -u origin develop                                         // push develop branch to fork

Don't forget to make develop branch as default one.

Let me know upgrading results for develop branch, please!
Thank you!

[raman-m]

The feature branch has been rebased onto ThreeMammals:develop! ✔️
All merge conflicts have been resolved successfully during rebase-operation! ✔️

@jlukawska
I thought you need a help in conflicts resolution.
We are now in the code review stage! 🎉

[raman-m]

@BrettJG As the issue #360 author,
Could you share your opinion regarding this solution please?

---

@netren20000 @iderbyshev @pliolis @lalocarbone @Phiph @mrclayman @jrsanbornjr @sachinjagdale @SebastianMajewski @falcopr @brettwinters @RickJNash @PraveenValavan
After your hot discussions for #360 in the past, I am inviting you to review this solution, plz.
So, I will appreciate your feedbacks!

[raman-m]

@Thanos06660 @fadil-khodabuccus-cko @CorporateActionMan @stodolos @madebykrol @akanmf @felipepiresdejesus
Welcome to code review session!
I know you've been waiting for this feature for years, but let's improve the quality of the solution. 😉

[raman-m]

@RaynaldM approved these changes on Apr 15

Ray, all the issues you reviewed have been resolved in the commit c727b93.
I will continue working for a bit longer, though no substantial changes are expected.

[raman-m]

Development Complete❕

Awaiting Final Code Reviews❗

[raman-m]

@ggnaegi Could you review please?

[raman-m]

@ggnaegi Take a look at the new static class in the Ocelot.DependencyInjection namespace!

[raman-m]

@ggnaegi So, this adds the feature. Additionally, you've restructured the code and introduced a new MessageInvokerPool feature at line 120: Services.AddOcelotMessageInvokerPool();.
I'm interested in expanding on this concept. It would be beneficial to have a feature-based design for Ocelot in the future.

[raman-m]

Ready for delivery ✅

• Code review ✔️✔️
• Team approvals ✔️✔️✔️
• Unit testing ✔️✔️✔️ →
  • UpstreamHeaderTemplatePatternCreatorTests
  • HeaderPlaceholderNameAndValueFinderTests
  • HeadersToHeaderTemplatesMatcherTests
  • extra FileConfigurationFluentValidatorTests, DownstreamRouteFinderTests
• Acceptance testing ✔️ → RoutingBasedOnHeadersTests
• Feature docs ✔️ → routing.rst

[raman-m]

@jlukawska Dear Jolanta,
After spanning over three years on this journey of development and code reviews, I am announcing that your feature has finally merged! 🎉

Congrats on this significant milestone! 🥳

Good job! Your dedication and hard work are truly appreciated. I hope to see you return to our project soon! 😇

P.S.

The feature will be officially released once all PRs associated with the Annual 2023 milestone are successfully closed.

• while the optimistic scenario anticipates a release by the end of April
• a more realistic outlook suggests that the release may occur in May

[raman-m]

Feature commit in develop → 6cef42e