JsonSerializerOptions.PropertyNamingPolicy not being applied to ProblemDetails output

[perbrage]

Hi,

Using the following code to apply snake_case property naming format, which works for all built-in stuff, but does not seam to work for problem details and the fluentvalidation extension.

In this image, the traceId should be named trace_id and "Born" should be "born"

So, it seems that ProblemDetails are defaulting to camelCase, and fluentvalidations are defaulting to PascalCase. Adding support for JsonSerializerOptions.PropertyNamingPolicy might solve this perhaps?

Regards, Per

[khellang]

Hi @perbrage! 👋🏻

The middleware relies on MVC's infrastructure and configured options for JSON serialization. The reason you're seeing differences from your configuration is that MVC (and this middleware) follows a standard, RFC 7808, that dictates the names of different properties. If you take a look at the source of ProblemDetails or ValidationProblemDetails, you'll see that the names are hard-coded according to the RFC, so no matter what your configuration says, it'll stay the same.

Unfortunately there's little I can do about it with this middleware. If you think it should be possible to configure serialization to deviate from the spec., you could try raising an issue with the ASP.NET Core devs 😅

[khellang]

The reason FluentValidation won't work with camel-/snake casing is because the property names are actually keys in a dictionary. JSON serialization is by default not configured to change dictionary keys as it breaks round-tripping. In order to achieve this, you need to either set DictionaryKeyPolicy on the JSON serialization options (assuming you're using System.Text.Json) or customizing FluentValidation's DisplayNameResolver or PropertyNameResolver.

[perbrage]

Thank you for your replies.

Regarding, "traceId", I understand that the property names should be named as specified in the RFC 7808, but if you look closely. the RFC does not mention anything regarding "traceId". In fact, you assign this name as a key in ProblemDetailsOptions.cs, line 276. Perhaps this is where you would want to honor the PropertyNamingPolicy assigned? If that would be honored, the ProblemDetails/ValidationProblemDetails would actually conform to both camelCase and snake_case.

Also, in the same file, there is a const for the exception DefaultExceptionDetailsPropertyName on line 15, which also is not part of the specification that could respect the PropertyNamingPolicy.

Just suggestions, thanks for reading.

[khellang]

Yeah, traceId is actually just to be compatible with MVC's default traceId property:

https://github.com/dotnet/aspnetcore/blob/a450cb69b5e4549f5515cdb057a68771f56cefd7/src/Mvc/Mvc.Core/src/Infrastructure/DefaultProblemDetailsFactory.cs#L92-L96

That's also related to dictionary keys, as it's all added to the Extensions dictionary. IMO, it's unfortunate that Newtonsoft/System.Text.Json has modeled this as a dictionary, as it really should be treated as JSON properties (and thus be transformed according to the PropertyNamingPolicy, see https://github.com/dotnet/runtime/issues/31167).

I guess I could run these property names through a configured naming policy, but at that point I'll have to start coupling to JSON serializer implementations, which I've avoided until now.

[perbrage]

I made a quick pull request you can review. It doesn't add a dependency on any serialization framework, and adds the configuration just as the ExceptionDetailPropertyName you already had.

[khellang]

Pushed to NuGet with v6.3.0 😄

[perbrage]

Very nice and fast :)

Just added it to my project, and now I got the errors dictionary and traceId in snake_case as the rest of the response.

Cheers!