Consider InputFormatter behavior when we can't read the charset

[rynowak]

An input formatter might be confused by a content type that is supported, with a charset parameter that isn't supported (via SupportedEncodings).

Today this results in the formatter returning true from CanRead and then adding a modelstate error when it's called to read the body.

We should just make this check part of CanRead, then it would go down the normal 'unsupported content type' path when the encoding isn't supported.

We should additionally double-check the behavior where a formatter has an empty SupportedEncodings. This should be allowed for binary content types that don't support/require a charset.

[rynowak]

See lots of discussion here: #3955 (comment)

[dougbu]

@rynowak thx for filing this.

Hoping we get rid of the last framework-provided error message that users can't override as part of the fix.

[rynowak]

Hoping we get rid of the last framework-provided error message that users can't override as part of the fix.

There will still be a message. You won't see it in the default configuration because the filter would prevent your method from being called. Is this enough?

[dougbu]

You won't see it in the default configuration because the filter would prevent your method from being called.

If by "your filter" you mean the CanRead() checks, seems fine. Even better if we add an Exception with current message to the ModelStateDictionary instead e.g. use new UnsupportedContentTypeException from #3955. Then wouldn't have anything additional to override.

[rynowak]

Yes. we would use the same mechanism. It would just go through the code path in @javiercn 's existing PR.

If by "your filter" you mean the CanRead() checks,

No I mean that if you remove the filter added in @javiercn 's PR. you would once again see these errors as model state errors instead of a 415.

[dougbu]

Works for me.

[Eilon]

Moving to backlog, please let me know if you feel otherwise.

[rynowak]

otherwise (if at all possible)

This is a pretty small follow up to some work we've already done.

[Eilon]

@javiercn please discuss with @rynowak @dougbu .

[javiercn]

As part of this change we've decided to split InputFormatters and OutputFormatters into two classes, InputFormatter and TextInputFormatter and OutputFormatter and TextOutputFormatter respectively.