What's the best way to inject custom request handling logic?

[Tadimsky]

We're looking at using Ocelot as a frontend to our services, but one of the things we'd like to be able to do is to take take over the request at some point if it matches certain criteria.

We need to do this to support data residency for our services. If a user's data location is set as some other country, then we need to be able to proxy the request to that country instead.
This proxied request would then hit the Ocelot frontend in the other location (where we would allow the request through as the location is correct).
We need the user to have authenticated first (so that we can lookup their location), so it would be nice to inject this handler somewhere in the Ocelot pipeline, but it doesn't seem like that's something that could be done right now from what I can see.

In addition to where the user is located, we also sometimes need to proxy a request to a region where the content itself is stored in (when it's not in the same location as the user's data should be). For this we'd want to be able to pull route parameters from the request and use those to fetch information about the content.
For example, if the route was /api/posts/{postId}, we'd want to be able to access the postId parameter and lookup the location of that post and proxy the user to that location instead.

We could do middleware before Ocelot even runs (and only use Ocelot for users that have their data stored in the country that the cluster is running in), but I'd love to integrate it more with Ocelot if possible.

I guess the other way of doing this would be to have a custom implementation of the part that gets the downstream route, but that also looks like it's too early in the pipe.

Ocelot/src/Ocelot/Middleware/Pipeline/OcelotPipelineExtensions.cs

Line 50 in 41d4f9c

builder.UseDownstreamRouteFinderMiddleware();

Would something like this be recommend with Ocelot?

[Tadimsky]

@yuft Yeah, that's what we're using right now actually and it's pretty good. Just a little more entangled with our services than we want it to be.
But yeah, definitely seems like Ocelot would be better as something to sit behind our reverse proxy for traffic into the cluster.

[raman-m]

Sorry, what's wrong with Ocelot?

[raman-m]

@Tadimsky Hi Jonno!
Welcome to the Ocelot world! 🐯

For example, if the route was /api/posts/{postId}, we'd want to be able to access the postId parameter and lookup the location of that post and proxy the user to that location instead.

If you need a bit more functionality than simple routing like: transforms, data conversions, integrations, analysis... then our Delegating Handler feature will help you.
So, you need to develop custom delegating handler with required functionality. So, integrate your lovely Location Lookup service to a custom delegating handler.

Finally, I'd say that development of a custom middleware will be an overhead approach. So, delegating handler works fine in your user scenario.