Optional [FromBody] Model Binding is not working

[toothache]

Describe the bug

I am trying to use optional [FromBody] model binding, for example,

[HttpPost("optional")]
public IActionResult PostOptional(WeatherForecast forecast = null)
{
    return Ok(forecast != null);
}

MVC options are configured as below to allow empty input in body:

services.AddControllers(options =>
{
    options.AllowEmptyInputInBodyModelBinding = true;
});

However, when requesting the API with an empty request body, I got the Error 415,

> curl --request POST -k -i 'https://localhost:5001/weatherforecast/optional' -d ''
HTTP/1.1 415 Unsupported Media Type
Date: Sun, 24 Jan 2021 05:23:26 GMT
Content-Type: application/problem+json; charset=utf-8
Server: Kestrel
Transfer-Encoding: chunked

{"type":"https://tools.ietf.org/html/rfc7231#section-6.5.13","title":"Unsupported Media Type","status":415,"traceId":"00-a2d12c1ee6e2844e9542de749df73d7d-b99cdaa84c27cd44-00"}%  (base) ➜  examples git:(yatengh/refactor_pages) ✗

To Reproduce

I'm using the sample code from https://github.com/pranavkm/OptionalBodyBinding. This is a sample code given from #6878.

Besides, I also targeted the project to netcore5. The bug still repos.

Exceptions (if any)

Further technical details

• ASP.NET Core version: 5.0.102
• Include the output of dotnet --info:

  .NET SDK (reflecting any global.json):
   Version:   5.0.102
   Commit:    71365b4d42
  
  Runtime Environment:
   OS Name:     Mac OS X
   OS Version:  10.13
   OS Platform: Darwin
   RID:         osx.10.13-x64
   Base Path:   /usr/local/share/dotnet/sdk/5.0.102/
  
  Host (useful for support):
    Version: 5.0.2
    Commit:  cb5f173b96
  
  .NET SDKs installed:
    2.1.400 [/usr/local/share/dotnet/sdk]
    3.1.405 [/usr/local/share/dotnet/sdk]
    5.0.102 [/usr/local/share/dotnet/sdk]
  
  .NET runtimes installed:
    Microsoft.AspNetCore.All 2.1.2 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.All]
    Microsoft.AspNetCore.App 2.1.2 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
    Microsoft.AspNetCore.App 3.1.11 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
    Microsoft.AspNetCore.App 5.0.2 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
    Microsoft.NETCore.App 2.1.2 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
    Microsoft.NETCore.App 3.1.11 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
    Microsoft.NETCore.App 5.0.2 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  
  To install additional .NET runtimes or SDKs:
    https://aka.ms/dotnet-download
  

• The IDE (VS / VS Code/ VS4Mac) you're running on, and its version
  From console.

[toothache]

After debugging this code, I'm able to work around it by introducing a custom InputFormatter. It overrides the following methods from InputFormatter.cs:

• request.ContentLength could also be null;

  aspnetcore/src/Mvc/Mvc.Core/src/Formatters/InputFormatter.cs

  Lines 105 to 116 in c925f99

  	var request = context.HttpContext.Request;
  	if (request.ContentLength == 0)
  	{
  	if (context.TreatEmptyInputAsDefaultValue)
  	{
  	return InputFormatterResult.SuccessAsync(GetDefaultValueForType(context.ModelType));
  	}
  	return InputFormatterResult.NoValueAsync();
  	}
  	return ReadRequestBodyAsync(context);

• CanRead ignores the value of TreatEmptyInputAsDefaultValue and early returns if the content body is empty or null.
  

  aspnetcore/src/Mvc/Mvc.Core/src/Formatters/InputFormatter.cs

  Lines 56 to 65 in c925f99

  	if (!CanReadType(context.ModelType))
  	{
  	return false;
  	}
  	var contentType = context.HttpContext.Request.ContentType;
  	if (string.IsNullOrEmpty(contentType))
  	{
  	return false;
  	}

[ghost]

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 7 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[brunolins16]

Related #39754