Backport/pr 42384 to release/7.0 preview7

[brunolins16]

Backport of #42384 to release/7.0-preview4

/cc @brunolins16

Adding ProblemDetailsService

Adding a new ProblemDetailsService responsible for consistent Problem Details generation.

Description

API Controllers have a mechanism to auto generated Problem Details (https://datatracker.ietf.org/doc/html/rfc7807) for API Controller ActionResult. The mechanism is enabled by default for all API Controllers, however, it will only generates a Problem Details payload when the API Controller Action is processed and produces a HTTP Status Code 400+ and no Response Body, that means, scenarios like - unhandled exceptions, routing issues - won't produce a Problem Details payload.

Here is overview of when the mechanism will produce the payload:

❌ = Not generated
✅ = Automatically generated

Routing issues: ❌

Unhandled Exceptions: ❌

MVC

• StatusCodeResult 400 and up: ✅ (based on SuppressMapClientErrors)
  • BadRequestResult and UnprocessableEntityResult are StatusCodeResult
• ObjectResult: ❌ (Unless a ProblemDetails is specified in the input)
  • eg.: BadRequestObjectResult and UnprocessableEntityObjectResult
• 415 UnsupportedMediaType: ✅ (Unless when a ConsumesAttribute is defined)
• 406 NotAcceptable: ❌ (when happens in the output formatter)

Minimal APIs won't generate a Problem Details payload as well.

Here are some examples of reported issues by the community:

• Usage of ProblemDetails is inconsistent throughout ASP.NET Core #32957
• ReturnHttpNotAcceptable=true Does Not Return ProblemDetails #16889
• ProblemDetails is not returned for 404NotFound and 500Exception #4953

This API introduce a new service that is consumed by Diagnostics Middlewares to have the ProblemDetails generated, for all Status 400+ and also have a mechanism that allows devs or library authors (eg. API Versioning) generate ProblemDetails responses when opted-in by the users.

Sample Usage

Default options

var builder = WebApplication.CreateBuilder(args);

// Add services to the containers
builder.Services.AddControllers();
builder.Services.AddProblemDetails();

var app = builder.Build();

// When problemdetails is enabled this overload will work even
// when the ExceptionPath or ExceptionHadler are not configured
app.UseExceptionHandler();

// Configure the HTTP request pipeline.
if (app.Environment.IsDevelopment())
{
    app.UseDeveloperExceptionPage();
}

//Generate PD for 400+
app.UseStatusCodePages();

app.MapControllers();
app.Run();

Fixes #42212

Customer Impact

This issue has been reported for years, including a community middleware is available to try fix the gap in the framework. This change does not replace the community middleware totally, however, enable the core functionality in the framework.

Regression?

• Yes
• No

Risk

• High
• Medium
• Low

This is a new API. The change to existing code is very small and non-impactful unless the new AddProblemDetails method is called.

Verification

• Manual (required)
• Automated

Packaging changes reviewed?

• Yes
• No
• N/A

[brunolins16]

The original approved via email backport PR (#42741) was merged targeting main instead of release/7.0-preview-7

[brunolins16]

@dotnet/aspnet-build Can I get help merging?

[dougbu]

@mmitche this was servicing-approved by Steve yesterday. Can we get it in now w/o disrupting your world❔

[mmitche]

Yep go for it.