UseReverseProxyPipelineMiddleware

[carsten-riedel]

Title

Add ergonomic API for composing YARP proxy pipeline middleware outside MapReverseProxy(...)

Description

Today, customizing the YARP proxy pipeline requires configuring it inline:

app.MapReverseProxy(proxyPipeline =>
{
    proxyPipeline.Use(async (context, next) =>
    {
        // policy / reroute / block
        await next();
    });

    proxyPipeline.UseSessionAffinity();
    proxyPipeline.UseLoadBalancing();
    proxyPipeline.UsePassiveHealthChecks();
});

This works, but it pushes a lot of logic into one large inline block and makes Program.cs harder to scan once multiple proxy-pipeline concerns exist (honeypot routing, IP/host rules, header policies, diagnostics, etc.).

For ASP.NET Core middleware, we can compose cleanly like:

app.UseMiddleware<A>();
app.UseMiddleware<B>();
app.UseMiddleware<C>();

It would be a large readability improvement to support a similar pattern for the YARP proxy pipeline.

Proposed API

Allow registering proxy pipeline “middleware” in a composable way, and then mapping the proxy endpoint once:

app.UseReverseProxyPipelineMiddleware<HoneypotIpMiddleware>();
app.UseReverseProxyPipelineMiddleware<HoneypotHostMiddleware>();
app.UseReverseProxyPipelineMiddleware<BlockHeaderMiddleware>();

app.MapReverseProxy(); // maps endpoint using registered proxy-pipeline middlewares + defaults

Or alternatively:

app.UseReverseProxyPipeline(conventions =>
{
    conventions.UseMiddleware<HoneypotIpMiddleware>();
    conventions.UseMiddleware<HoneypotHostMiddleware>();
});

app.MapReverseProxy();

Semantics

The key question is scope. Suggested semantics:

• Registered proxy-pipeline middlewares are applied to the next MapReverseProxy() call (endpoint-scoped), similar to endpoint conventions.
• (Optional) an overload to apply to all proxy endpoints if the app maps multiple reverse-proxy endpoints.

This avoids ambiguity and preserves the existing ability to create multiple reverse-proxy endpoints with different pipelines.

Why this helps

• Readability: keeps Program.cs slim and linear.
• Encapsulation: each proxy step is a real middleware class (DI + unit testing friendly).
• Consistency: aligns with normal ASP.NET Core middleware composition patterns.
• Avoid inline lambdas: large proxy pipelines become manageable and reusable.

Workaround today

It’s possible to implement a custom extension that stores middleware types and applies them inside a custom MapReverseProxyWith... helper, but an official API would be more discoverable and avoid custom plumbing.

[MihaZupan]

I'm not sure I really understand the request.

If you want to keep your logic separate/reusable, you can already extract it to a helper method

app.MapReverseProxy(proxyPipeline =>
{
    ConfigureProxyApp(proxyPipeline);
    proxyPipeline.UseLoadBalancing();
});

app.Run();

void ConfigureProxyApp(IReverseProxyApplicationBuilder app)
{
    app.UseMiddleware<MyMiddleware>();
    app.UseSessionAffinity();
}

---

app.UseReverseProxyPipeline(conventions =>
{
    conventions.UseMiddleware<HoneypotIpMiddleware>();
    conventions.UseMiddleware<HoneypotHostMiddleware>();
});

app.MapReverseProxy();

I'm not sure I see why that would be better than

app.MapReverseProxy(app =>
{
    app.UseMiddleware<HoneypotIpMiddleware>();
    app.UseMiddleware<HoneypotHostMiddleware>();
});

[carsten-riedel]

Sorry, my earlier wording may have been a bit misleading.

Totally agree the current design makes sense and it works fine - this is not blocking me.

I just really dislike the "configure via inline lambda" style in Program.cs. Once the app grows, that lambda tends to become a mega-block (evaluating, headers, , feature flags, etc.), which mixes real logic into the wiring file.

My request is purely about clean code / separation of concerns: I want to push the logic out of the mapping lambda almost completely into reusable, DI-friendly components with middleware-like behavior, and keep Program.cs as "order/wiring only".

If the answer is "do this as an extension/helper today", that is fine - but having an official small hook or recommended pattern would avoid everyone reinventing slightly different helpers and would stay aligned with future pipeline changes.

So why lamda required by design...

app.MapReverseProxy(app =>
{
    app.UseMiddleware<HoneypotIpMiddleware>();
    app.UseMiddleware<HoneypotHostMiddleware>();
});