Issue with multipart/form-data post and json.net deserializtion (using interfaces)

[mbonatsos]

We use the aspnetcore 2.

We have configured JsonOptions in startup like this.

services.AddMvc().AddJsonOptions(options =>
            {
                options.SerializerSettings.ContractResolver = new DefaultContractResolver();
                options.SerializerSettings.Converters = new List<JsonConverter> {
                    new JsonDocumentConverter(),
                    new JsonDocumentMetaConverter(),
                    //new Bll.FileRecords.JsonDocumentMetaListConverter(),
                };
            });

public class JsonDocumentConverter : CustomCreationConverter<IDocument>
    {
        public override IDocument Create(Type objectType)
        {
            return new LocalDocument();
        }
    }
public class JsonDocumentMetaConverter : CustomCreationConverter<IDocumentMeta>
    {
        public override IDocumentMeta Create(Type objectType)
        {
            return new LocalDocumentMeta();
        }
    }

In our controller we have 2 methods

1. The first one is called PostUrlencoded in which we make a http post request with content-type : application/x-www-form-urlencoded.

[HttpPost("PostUrlencoded")]
public async Task<IActionResult> PostUrlencoded([FromBody]IDocument document)
{ /*...*/ }

2.. The second one is called PostΜultipart in which we make a http post request with content-type : multipart/form-data.

[HttpPost("PostΜultipart")]
public async Task<IActionResult> PostΜultipart([FromForm]IDocument document)
{ /*...*/ }

The first method works fine, and the deserialization works fine. In the second method deserialization fails.
The error is:
Model bound complex types must not be abstract or value types and must have a parameterless constructor.

That's because the JsonOptions isn't applied.

When we remove the jsonOptions from the startup.cs, we get the same error in both cases.

[tangdf]

If you use the Fromform attribute, the model's binding is not using JSON.NET.

[mbonatsos]

Why is this happening?

The http request is sent like this

--d76a5e72-cf14-4a63-ab96-44b45457a6a5
Content-Type: application/json; charset=utf-8
Content-Disposition: form-data; name=document
{...json..}

Shouldn't this be deserialized?

[mkArtakMSFT]

@mbonatsos , can you please share a sample project with us to reproduce the issue?

[tangdf]

https://docs.microsoft.com/en-us/aspnet/core/mvc/models/model-binding#customize-model-binding-behavior-with-attributes
[FromHeader], [FromQuery], [FromRoute], [FromForm]: Use these to specify the exact binding source you want to apply.
[FromBody]: Use the configured formatters to bind data from the request body. The formatter is selected based on content type of the request.

[mbonatsos]

I've created a sample project for you to see the issues and the workarounds.
In my opinion the modelbinder solution is not clean.

The mvc framework should deserialize a model from some data that is posted (http), regardless what the post request type is "multipart/form-data" or "application/x-www-form-urlencoded".

Sample.zip

[mkArtakMSFT]

@dougbu , can you please investigate this?

[dougbu]

The JSON input formatter accepts application/json, text/json and application/*+json. It does not support any multipart content types by default.

To support multipart and input formatters together, need to position the Body stream after the boundary for the appropriate section. See https://github.com/aspnet/Entropy/blob/dev/samples/Mvc.FileUpload/Controllers/FileController.cs for example. (This isn't simple. MVC helps most when combining files and application/x-www-form-urlencoded sections into a multipart/form-data submission. That is the normal use of multipart/form-data.)

As a smaller detail, also need to update the JsonInputFormatter because it will check the overall content type, not that of the "current" section. E.g. in your ConfigureServices(IServiceCollection services):

services.AddMvc(options =>
{
    var jsonInputFormatter = options.InputFormatters.OfType<JsonInputFormatter>().First();
    jsonInputFormatter.SupportedMediaTypes.Add("multipart/form-data");
};

[dougbu]

Clearing the investigate label.

[dougbu]

I probably misunderstood the concern, focusing on using input formatters with multipart requests.

The sample contains a number of issues:

• [FromBody] and [FromForm] are completely separate. E.g. nothing in MvcJsonOptions is used when binding [FromForm] parameters.
• Requests matching actions with [FromForm] parameters must contain an application/form-url-encoded body or a multipart/form-data body with an application/x-www-form-urlencoded sectoin. The tests sending application/json data to actions with [FromForm] parameters led to my earlier confusion.
• Binding [FromForm] Document document parameters should work fine given a valid request (see above) and the default configuration.
• Binding [FromForm] IDocument document parameters requires an IModelBindingProvider implementation that gets the metadata for Document and returns the associated binder. Should not need a specific binder (just use ComplexTypeModelBinder) e.g.

  if (context.Metadata.ModelType == typeof(IDocument))
  {
      var metadata = context.MetadataProvider.GetMetadataForType(typeof(Document));
      return context.CreateBinder(metadata);
  }

• Add the above IModelBindingProvider implementation last, certainly after the BodyModelBindingProvider. Otherwise, the ComplexTypeModelBinder will attempt to bind when the request contains application/json data -- and fail.
• IFormFile action parameters should not have an associated [FromForm] attribute.

[xrkolovos]

I believe and would expect the mvc framework to deserialize this http request, with out any other configuration.
I would also expect [FromForm] working in the same way with [FromBody] for the deserialization of posted data. I mean that if i post this

--d76a5e72-cf14-4a63-ab96-44b45457a6a5
Content-Type: application/json; charset=utf-8
Content-Disposition: form-data; name=document
{...json..}

MvcJsonOptions should be used/respected. Is confusing not to work there.

I also think that the implementation with IModelBindingProvider is not so clean.

[xrkolovos]

I would like to see some more opinions from other team members.

[mkArtakMSFT]

Thank you for your feedback.
We're closing this issue as the behavior discussed seems to be by design.

[xrkolovos]

I am not conviced that the behavior should be this.
I coundm't understand the arguments behind this decision.

I always hear from the members of the asp.net team in confernces and videos that the framework is openly developed, not only open source.

I ask for more info about this and you close the issue not fair.