Middleware Injection

Warning, use with caution! If you are seeing any exceptions or strange behavior in your middleware pipeline and you are using any of the following. Remove them and try again!

When setting up Ocelot in your Startup.cs you can provide some additional middleware and override middleware. This is done as follows:

var configuration = new OcelotPipelineConfiguration
{
    PreErrorResponderMiddleware = async (context, next) =>
    {
        await next.Invoke();
    }
};
app.UseOcelot(configuration);

In the example above the provided function will run before the first piece of Ocelot middleware. This allows a user to supply any behaviors they want before and after the Ocelot pipeline has run. This means you can break everything, so use at your own pleasure!

The user can set functions against the following (see more in the OcelotPipelineConfiguration class):

  • PreErrorResponderMiddleware injection is already explained above.

  • PreAuthenticationMiddleware injection allows the user to run pre authentication logic and then call Ocelot authentication middleware.

  • AuthenticationMiddleware overrides Ocelot authentication middleware. [1]

  • PreAuthorizationMiddleware injection allows the user to run pre authorization logic and then call Ocelot authorization middleware.

  • AuthorizationMiddleware overrides Ocelots authorization middleware. [1]

  • PreQueryStringBuilderMiddleware injection allows the user to manipulate the query string on the http request before it is passed to Ocelot request creator.

Obviously you can just add mentioned Ocelot middleware overridings as normal before the call to app.UseOcelot(). It cannot be added after as Ocelot does not call the next Ocelot middleware overridings based on specified middleware configuration. So, the next called middlewares will not affect Ocelot configuration.

ASP.NET Core Middlewares and Ocelot Pipeline Builder

Ocelot pipeline is a part of entire ASP.NET Core Middlewares conveyor aka app pipeline. The BuildOcelotPipeline method encapsulates Ocelot pipeline. The last middleware in the BuildOcelotPipeline method is HttpRequesterMiddleware that calls the next middleware, if added to the pipeline.

The internal HttpRequesterMiddleware is part of the pipeline but it is private and cannot be overridden, since this middleware does not belong to the list of user’s public ones that can be overridden! So, this is the last middleware of the entire Ocelot and ASP.NET pipeline, and it handles non-user operation. The last user (public) middleware that can be overridden is PreQueryStringBuilderMiddleware being read from the pipeline configuration object, see previous section.

Considering that PreQueryStringBuilderMiddleware and HttpRequesterMiddleware are the last user and system middlewares, there are no other middlewares in the pipeline at all. But you can still extend the ASP.NET pipeline, as shown in the following code:

app.UseOcelot().Wait();
app.UseMiddleware<MyCustomMiddleware>();

But we do not recommend adding this custom middleware before or after calling of UseOcelot() as it affects the stability of the entire pipeline and has not been tested. Such kind of custom pipeline building is out of the Ocelot pipeline model and the quality of the solution is at your own risk.

Finally, do not get confused about the distinction between system (private, non-overridden) and user (public, overridden) middlewares. Private middlewares are hidden and cannot be overridden, but the entire ASP.NET pipeline can still be extended. The public middlewares are fully customizable and can be overridden.

Future

The community shows an interest in adding more overriden middlewares. One of such request is PR 1497, and possibly it will be included in a next upcoming release.

Anyway, in your opinion, if current overriden middlewares do not provide enough pipeline flexibility, you can open new topic in Discussions space of the repository. octocat