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

[hugoqribeiro]

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.

[pranavkm]

Couldn't you wrap UseHttpLogging in a app.UseWhen to achieve this?

[hugoqribeiro]

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

[BrennanConroy]

Similar to #31844

Thanks for contacting us.

We're moving this issue to the .NET 7 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[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 #43222.