aspnetcore
aspnetcore copied to clipboard
dotnet
fixed DefaultProblemDetailsWriter Doesn't Handle Media Type Subsets #52577
Fixed issue where DefaultProblemDetailWriter doesn't handle media type subsets. Added test cases including media type subsets. The corresponds with Issue#52577 tagged help wanted.
Thanks @MythoclastBM! I left some comments. Apart from some minor style stuff, I'm curious why you left an extra clause in the check that was there before. I assumed you'd just flip the two existing ones.
Will we see this change in a patch release of .Net 8? Or do we have to wait for .Net 9?
@tore-hammervoll This change isn't being back ported. We typically only backport things if there is a big enough demand for it. If this is blocking you, let me know.
We got around most cases of this issue by ensuring we write the problems with DefaultApiProblemDetailsWriter instead of DefaultProblemDetailsWriter. This handles content negotiation in a much more consistent way. The missing piece of the puzzle was passing the original endpoint metadata on to the IProblemDetailsService.TryWrite, from our custom IExceptionHandler implementations similarly to the way it's done in ExceptionHandlerMiddlewareImpl: https://github.com/dotnet/aspnetcore/blob/aefa4caf03a14c566188ebe0bb35442291e4b772/src/Middleware/Diagnostics/src/ExceptionHandler/ExceptionHandlerMiddlewareImpl.cs#L194
The only case I've discovered that falls back to the DefaultProblemDetailsWriter now is requests to paths that don't hit any controller action. These errors will then use the lacking content negotiation of this implementation, and may result in an empty body or a simple textual error. If a problem details response is written, it will also be missing the traceId field due to https://github.com/dotnet/aspnetcore/issues/54325. We don't use minimal apis yet, only controllers still, so this issue is very minor for us.
The only case I've discovered that falls back to the DefaultProblemDetailsWriter now is requests to paths that don't hit any controller action.
I see. If this becomes a serious problem, you can file an issue on the repo and we can make a decision around backporting with that specific context in mind.