Produces attribute does not honor Accept header.

[klepeis]

Describe the bug

The ConsumesAttribute appears to honor the content-type header returning a 415 if there is a mismatch here. I was wondering why there is not similar behavior on the ProducesAttribute to honor the accept header.

To Reproduce

1. Create a new WebApi project in .Net Core 3.1
2. Add the [Produces("application/vnd.api+json")] attribute to the Get method in the controller.
3. In startup.cs add the following

services.AddControllers(config =>
            {
                config.RespectBrowserAcceptHeader = true;
                config.ReturnHttpNotAcceptable = true;
            });

Attempt to hit the API using your tool of choice.
Set the accept header in the request to "application/json" You will get a successful result with a content-type of application/vnd.api+json.

I get that the "Produces" attribute will always force the result of an API to before formatted as the type listed in the attribute, but if the accept header provided doesn't match the expected output type of an API does that not warrant a 406, especially in the case where RespectBrowserAcceptHeader is enabled?

Exceptions (if any)

Further technical details

• ASP.NET Core version 3.1.200
• Include the output of dotnet --info
• The IDE (VS / VS Code/ VS4Mac) you're running on, and it's version VS 2019 Enterprise 16.8.2

[javiercn]

@klepeis thanks for contacting us.

The produces attribute will influence the content type of the result and that will ultimately result in content negotiation failing, which should result in a 406 response.

Can you provide a minimal repro project and a sample request so that we can better understand what you believe is not working?

[klepeis]

Please find the sample project in the zip below. I put some comments in the controller to add some color. I also provided a Postman collection with the various requests I am testing.

I did look through the ProducesAttribute code on Github and it doesn't look like in this attribute there is any logic to return a 406 where the ConsumesAttribute will return a 415.

In the HTTP Spec on w3.org it does mention for the 406 that it is uncommon for a 406 to be returned and that often it is preferred to return the response in the incorrect format that using the status code. But I would have hoped that would have been an option or tied to the MvcOption of ReturnHttpNotAcceptable.

WebApplication5.zip

[ghost]

Thanks for contacting us. We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[ghost]

Thanks for contacting us. We're moving this issue to the .NET 7 Planning milestone for future evaluation / consideration. Because it's not immediately obvious that this is a bug in our framework, we would like to keep this around to collect more feedback, which can later help us determine the impact of it. We will re-evaluate this issue, during our next planning meeting(s). If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[ghost]

Thanks for contacting us. We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. Because it's not immediately obvious that this is a bug in our framework, we would like to keep this around to collect more feedback, which can later help us determine the impact of it. We will re-evaluate this issue, during our next planning meeting(s). If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.