DefaultProblemDetailsWriter Doesn't Handle Media Type Subsets #52577
Labels
area-networking
Includes servers, yarp, json patch, bedrock, websockets, http client factory, and http abstractions
help wanted
Up for grabs. We would accept a PR to help resolve this issue
Milestone
Is there an existing issue for this?
Describe the bug
The
DefaultProblemDetailsWriter
is meant to support clients that specify a media type in theAccept
header field that is compatibleapplication/json
orapplication/problem+json
:aspnetcore/src/Http/Http.Extensions/src/DefaultProblemDetailsWriter.cs
Line 13 in 3c58bce
The matching logic, however, is inverted:
aspnetcore/src/Http/Http.Extensions/src/DefaultProblemDetailsWriter.cs
Line 42 in 3c58bce
The correct logic should be:
Expected Behavior
A client that specifies a more specific media type should be matched by
DefaultProblemDetailsWriter.CanWrite
. This happens becauseMediaTypeHeaderValue.IsSubsetOf
considers media type parameters:aspnetcore/src/Http/Headers/src/MediaTypeHeaderValue.cs
Line 385 in 8efa82d
The source code cites RFC 2068 §14.1 which has been superseded by RFC 2616, RFC 7230, and is currently defined by RFC 9110 §12.5.1. A media type is identified by
<type>/<subtype>[+<suffix>]*
. The documentation forMediaTypeHeaderValue.IsSubsetOf
also states:This means that:
application/json; charset=utf-8
application/json; v=1.0
should be considered subsets of
application/json
. Currently, they are not because the logic is inverted. These scenarios were missed because the test cases do not include a variant which includes a media type parameter:aspnetcore/src/Http/Http.Extensions/test/ProblemDetailsDefaultWriterTest.cs
Line 541 in 8efa82d
Steps To Reproduce
The following scenarios assume that a problem has occurred on the server.
Example 1
Although not officially supported as part of
application/json
, it is commonplace for message exchanges to use the media type parametercharset=utf-8
as opposed toAccept-Charset
, which is arguably the correct approach. If a problem occurs, no problem details are reported as a result.HTTP/2 400 Bad Request
Example 2
A truly RESTful API would version itself using media type negotiation, which might be achieved using a media type parameter. If a problem occurs or the version is not supported, no problem details are reported.
HTTP/2 415 Unsupported Media Type
Exceptions (if any)
InvalidationOperationException
isIProblemDetailsService.WriteAsync
is used versusIProblemDetailsService.TryWriteAsync
..NET Version
8.0.100
Anything else?
The text was updated successfully, but these errors were encountered: