Allow ProblemDetails property to be settable in ProblemDetailsContext

[bjornen77]

Background and Motivation

Currently the ProblemDetail property in ProblemDetailsContext is init only, which makes it impossible to change the ProblemDetails instance to another type if wanted when customizing the problem details.

For example, when sending invalid JSON to an API controller a validation problem is returned. If I would like to change this to another problem details type, the property needs to be settable.

Proposed API

namespace Microsoft.AspNetCore.Http;

public class ProblemDetailsContext
{
-   public ProblemDetails ProblemDetails { get; init; }
+   public ProblemDetails ProblemDetails { get; set; }
}

Usage Examples

builder.Services.AddProblemDetails(options =>
{
    options.CustomizeProblemDetails = (context) => 
    {
        if (context.ProblemDetails is HttpValidationProblemDetails)
        {
            // change to another problem details type because the HttpValidationProblemDetails contains
            // an Errors property that might not be wanted in some cases.
            context.ProblemDetails = new ProblemDetails() { .... }
        }
    };
});

Alternative Designs

N/A

Risks

Investigate so it has no side effect of substituting the problem details instance here,

[mitchdenny]

The structure of the problem type is largely dictated by RFC7807. Even though the ProblemDetails field is init only, nothing stops you adding information to the Extensions property which is the intended extensibility point.

Hi @bjornen77. We have added the "Needs: Author Feedback" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.

[bjornen77]

If a validation problem(HttpValidationProblemDetails) is returned from a controller, which is done automatically in som cases, for example invalid JSON in the body, it will contain an "errors" property. The errors propery will contain information about the error from the json serialiser, for example:

"type": "https://tools.ietf.org/html/rfc7231#section-6.5.1",
  "title": "One or more validation errors occurred.",
  "status": 400,
  "traceId": "00-341f9a008e6f0be700b27e4581f72b6f-2ae1db82e25bfa23-00",
  "errors": {
    "$": [
      "Expected depth to be zero at the end of the JSON payload. There is an open JSON object or array that should be closed. Path: $ | LineNumber: 9 | BytePositionInLine: 0."
    ]
.....

For example in production, there could be a need of providing a different problem details message, without this "errors" information.

I know that I can clear the "errors" if checking if the type is an "HttpValidationProblemDetails" and then call
httpValidationProblemDetails.Errors.Clear()
but the "errors" will still be present, even though it is empty.

I also found that I might be able to register a custom implementation of IClientErrorFactory if I set SuppressMapClientErrors to true.

But I think that the proposed change above will be easier, thoughts?

[mitchdenny]

@bjornen77 could you update this issue to use the API proposal template and we can try to get some collective input on whether we want to make this change.

I'm not sure if there would be a side effect of substituting the problem details instance here, but it is worth considering.

Template: https://github.com/dotnet/aspnetcore/issues/new?assignees=&labels=api-suggestion&template=30_api_proposal.md&title=

Tag me when you've got this updated, I'll happily float this for you at our next API review.

Hi @bjornen77. We have added the "Needs: Author Feedback" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.

[bjornen77]

@mitchdenny Sure, no problem! The issue is now updated with the API proposal template.