Response Content-Type header doesn't indicate the version

[douggish]

When using the media type versioning, it is possible for a request to specify multiple media types in the accept header (e.g. "application/json; v=1.0, application/json; v=2.0") on a GET request. However, the response just has a Content-Type header of "application/json", so the client doesn't know which version was returned. It seems like the Content-Type header in the response should indicate the version (e.g. "application/json; v=2.0") of the response that was actually returned.

I'm using:
Microsoft.AspNetCore.Mvc.Versioning 3.0.0
Microsoft.AspNetCore.Mvc.Versioning.ApiExplorer 3.0.0

[commonsensesoftware]

Currently, this is not supported. The existing implementation selects the version from the media type with the highest quality (as seen here). Since these media types have the same quality, it's coincidence that you're getting 2.0. If you reversed the order, I would expect you to get 1.0. This happens because there are distinct phases between reading the raw API version value and parsing it. Parsing is delayed as long as possible so that an appropriate response can be given (as opposed to trying to deal with an exception in the middle of the pipeline).

Requesting multiple API versions is currently not supported. In any other context (e.g. query string or header), you should have received a 400 with AmbiguousApiVersion. The only reason that doesn't happen with media types is because the quality can be used to weigh (e.g. disambiguate) the best choice. There isn't a mechanism to select an appropriate API version from a set of inputs. In addition, it would have to be delayed far into the pipeline (for parsing) or a service author would be left to their own parsing and evaluation. Ultimately, the client should be only asking for a single API version. I can think of scenarios of where requesting multiple versions might be useful (ex: 1.0-RC or 1.0), but there's a lot of devil in the details, which is why it's not supported. Furthermore, in practice, I've never seen that needed. If client cares about the version, they typically want a specific version.

Reporting the selected API version isn't unreasonable, but given that only a single API version is matched, it shouldn't be necessary. There's no other context - yet, in which you get the matched API version back. I'm not opposed to the idea, but I need to make sure it's feasible. It may not be possible in all cases based on when the headers are written and who writes them. I believe the content type is written by the IOutputFormatter.

If you have version symmetry across your APIs, then it's possible for you to create a custom IApiVersionReader to handle this. That's possible because you know all the versions in your application ahead of time. API versioning doesn't have a why to reliably do that for you. It has to wait until a route candidate is matched before it can determine available versions. In a similar way, you should be able to add or update the version in the Content-Type header with a couple of different, standard ASP.NET extensibility points. It might also be worth investigating how browser clients handle media type parameters.