105c99cbf2
The change here is to always use the provided formatter, instead of using it as a fallback. This is much less surprising for users. There are some other subtle changes here and cleanup of the tests, as well as documentation additions. The primary change is that we still want to run 'select' on a formatter even if it's the only one. This allows us to choose a content type based on the accept header. In the case of a user-provided formatter, we'll try to honor the best possible combination of Accept and specified ContentTypes (specified ContentTypes win if there's a conflict). If nothing works, we'll still run the user-provided formatter and let it decide what to do. In the case of the default (formatters from options) we do conneg, and if there's a conflict, fall back to a global (from services) JsonOutputFormatter - we let it decide what to do. This should leave us with a defined and tested behavior for all cases. |
||
|---|---|---|
| .. | ||
| ActivatorWebSite | ||
| AddServicesWebSite | ||
| AntiForgeryWebSite | ||
| ApiExplorerWebSite | ||
| ApplicationModelWebSite | ||
| AutofacWebSite | ||
| BasicWebSite | ||
| CompositeViewEngine | ||
| ConnegWebSite | ||
| FilesWebSite | ||
| FiltersWebSite | ||
| FormatterWebSite | ||
| InlineConstraintsWebSite | ||
| Microsoft.AspNet.Mvc.TestConfiguration | ||
| ModelBindingWebSite | ||
| PrecompilationWebSite | ||
| RazorInstrumentationWebsite | ||
| RazorWebSite | ||
| RoutingWebSite | ||
| TagHelpersWebSite | ||
| UrlHelperWebSite | ||
| ValueProvidersSite | ||
| VersioningWebSite | ||
| ViewComponentWebSite | ||
| WebApiCompatShimWebSite | ||
| XmlSerializerWebSite | ||