Fix content negotiation content-type check for InputFormatter

[andresmoschini]

From InputFormatter.cs

public virtual bool CanRead(InputFormatterContext context)
{
    // . . .
    return SupportedMediaTypes
        .Any(supportedMediaType => supportedMediaType.IsSubsetOf(requestContentType));
}

If I am not wrong, to be able to read a request, requestContentType should be a subset of any of InputFormatter's SupportedMediaTypes.

[andresmoschini]

For example, I set:

formatter.SupportedMediaTypes.Add(new MediaTypeHeaderValue("*/*"));

and I get Unsupported content type 'text/plain; charset=UTF-8'..

But it works if I set:

formatter.SupportedMediaTypes.Add(new MediaTypeHeaderValue("text/plain"));

Is this behavior expected?

[dougbu]

It's possible there's a bug in how IsSubsetOf() handles */* however the real answer for your scenario is to override CanRead() to return true since that seems to be what you want.

[dougbu]

Put another way, InputFormatter handles a specific selection of concrete formatters. A catch-all formatter should probably implement IInputFormatter directly.

[andresmoschini]

Thanks @dougbu, but it was only an example.

I think that an InputFormatter should be capable to read all request with content-type that are subtypes of SupportedMediaTypes. Am I missing something?

[dougbu]

Do you have a concrete example that fails which doesn't involve */*? Better yet do you have a small repro project we could use to investigate what you're seeing -- even if with */*?

Note what you're doing with the catch-all formatter (i.e. that accepts */*) should work. My alternate implementation was based on the semantics you need rather than a thought your issue was invalid.

[andresmoschini]

Thanks for your help @dougbu, since I need to ignore request content type, in my project I will override CanRead() as you mention.

BUT, I am pretty sure that I am not understanding how to InputFormaters deal with content-type header, OR there is a mistake in the implementation.

It is not necessary a small project because there are already a test.

In my opinion that test is wrong because it says that if request's content-type is application/* should be accepted by JsonInputFormatter. It seems to be valid for accept header, but not for content-type.

CC: @harshgMSFT

[danroth27]

Looks like the IsSubset check is backwards - we should check that the request media type is a subset of the supported media type, not the other way around.

[dougbu]

Yes, the check is incorrect. Some non-exact matches start working after reversing it.

None of the in-box input formatters support wildcard media types or subtypes. This reduces the impact slightly.

Confirmed the Web.API 3 check matches what we have in MVC 6. See that version's MediaTypeFormatterCollection.FindReader() and HttpContentExtensions.ReadAsync(). We carried this bug forward.

[dougbu]

Moving to early in RC1.

The reversed check hid a couple of other bugs. While I have an implementation that covers most issues, we've revised the design to improve correctness, especially around formatter selection. Will take a bit more work...

[dougbu]

• aspnet/HttpAbstractions@0581bcf
• 03625c3
• 9b00461