Returning HTML using Produces("text/html") causes 406 response

[mohd-akram]

After upgrading to ASP.NET Core 2.0, [Produces("text/html")] doesn't seem to work anymore. I am returning a string in my action using Ok(str) with that attribute specified.

[Eilon]

@mohd-akram can you show what your action method looks like? And what kind of request is being sent to the server?

[mohd-akram]

Using dotnet new mvc and modifying HomeController:

[Produces("text/html")]
public IActionResult Index()
{
    return Ok("hello");
}

Using Chrome:

Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding:gzip, deflate, br
Accept-Language:en-US,en;q=0.8
Cache-Control:no-cache
Connection:keep-alive
Cookie:_ga=GA1.1.255538139.1497605335
Host:localhost:5000
Pragma:no-cache
Upgrade-Insecure-Requests:1
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3138.0 Safari/537.36

In console:

warn: Microsoft.AspNetCore.Mvc.Internal.ObjectResultExecutor[1]
      No output formatter was found for content type 'text/html' to write the response

[Eilon]

@mohd-akram thanks for the info!

@rynowak / @dougbu - ideas on this? Does the OkResult somehow not participate in con-neg?

[davidfowl]

@Eilon what formatter is registered for text/html by default? AFAIK, none...

[Eilon]

Oh right text/html, I totally missed that - was thinking plaintext... yeah probably nothing is registered.

[davidfowl]

@mohd-akram are you saying this worked in 1.x?

[mohd-akram]

Yeah. The docs seem to support this.

I've added this for now:

public class HtmlOutputFormatter : StringOutputFormatter
{
    public HtmlOutputFormatter()
    {
        SupportedMediaTypes.Add("text/html");
    }
}

services.AddMvc(options => options.OutputFormatters.Add(new HtmlOutputFormatter()));

[davidfowl]

Yes this looks like a regression. I reproduced it working with 1.1 and then failing after an upgrade.

[rynowak]

This was an intentional change aspnet/Mvc#4945

We used to have a formatter that would just barf out any string that you gave it. It caused a lot of confusion every time it kicked into action.

This is what ContentResult does. If you know ahead of time what content type and have the content in a string, just use that.

[mohd-akram]

It feels like there is a middle ground here i.e. respecting Produces and returning 406 otherwise?

[rynowak]

The StringOutputFormatter used to ignore content types entirely and it no longer does this - it will only output text/plain. If you want it to output strings as text/html then you can add that as well.

options.OutputFormatters.OfType<StringOutputFormatter>().Single().SupportedMediaTypes.Add("text/html");

---

Personally I would just use Content(...) for this. You have the HTML text, and the content type already decided. This doesn't rely on serialization nor on content negotiation.

[mohd-akram]

That's perfect, thanks! Yeah, but I can't specify a status code (easily) that way. I prefer using Ok, BadRequest, NotFound, etc.

[rynowak]

Should we add a status code to to content? Or is the issue mostly that you like the semantically meaningful names like Ok, BadRequest?

[mohd-akram]

Mostly the semantic names, but I still think adding a status code to Content (and View) would be helpful.

[Eilon]

For the particular scenario that started this issue, we recommend using the workaround listed by adding the supported MIME type(s) to the existing formatter.

What we are considering is adding new action result type (or factory helpers), plus making setting the status code easier on existing action result types.

Putting this on the Backlog for future consideration.