HttpLoggingMiddleware could allow custom code to decide whether to log or not

Background and Motivation

The HttpLoggingMiddleware added recently works based on configuration options in HttpLoggingOptions.

The currently implementation is basically all or nothing. You either add the middleware or not. Even if you can decide what is redacted or not and if request/response bodies are included.

It would be nice if HttpLoggingOptions included a delegate to let the application (custom code) decide whether to log or not for a specific request.

Proposed API

namespace Microsoft.AspNetCore.HttpLogging
{
    public sealed class HttpLoggingOptions
    {
+       public Func<HttpContext, bool> Selector { get; set; } = context => true;
    }
}

Usage Examples

• Log only failed requests.
• Log request body only for specific endpoints.

Alternative Designs

You can implement your own middleware but that beats the whole purpose of implementing this feature in the framework. An alternative would be to make HttpLoggingMiddleware public and add some kind of extensibility to it. At least one could implement that custom middleware but reuse the framework implementation (e.g. request buffering).

Risks

The risk is that performance of HTTP logging would depend on the custom code implemented in the delegate.

[Tratcher]

Rather than on/off, you’d want something more granular like HttpLoggingFields (and return None for off).

namespace Microsoft.AspNetCore.HttpLogging
{
    public sealed class HttpLoggingOptions
    {
+       public Func<HttpContext, HttpLoggingFields>? FieldSelector { get; set; } 
    }
}

This is similar to the proposed endpoint attribute in https://github.com/dotnet/aspnetcore/issues/43222.

[hugoqribeiro]

UseWhen would problably work better for the “log only for specific endpoints”. It would not help for the “log only failed requests” right?