Minimal API with IFormFile throws when request body is missing and Content-Type header is missing or empty

[balazsmeszegeto]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

Having an endpoint with Minimal API and IFormFile:

app.MapPost("/upload", (IFormFile file) => "ok");

Sending a request with incorrect Content-Type, ie:

curl --request POST 'http://localhost:5000/upload' --header 'Content-Type: foo'

will return 415 status, as expected. However, missing or empty (spaces) Content-Type, ie:

curl --request POST 'http://localhost:5000/upload'
curl --request POST 'http://localhost:5000/upload' --header 'Content-Type:'
curl --request POST 'http://localhost:5000/upload' --header 'Content-Type:  '

will throw InvalidOperationException and return 500. I am not 100% familiar with the code in this area (yet), but my understanding is that routing constraint won't exclude the endpoint for missing/empty Content-type, and then parameter binding will throw, while attempting to read HttpRequest.Form. The exception thrown is related to this issue: #49096

Tried changing the signature, with attribute and optional, same behaviour:

app.MapPost("/upload", ([FromForm] IFormFile file) => "ok");
app.MapPost("/upload", ([FromForm] IFormFile? file) => "ok");
app.MapPost("/upload", (IFormFile? file) => "ok");

Expected Behavior

I expect that for endpoints with IFormFile (or its variations like IFormFileCollection) parameters, only valid Content-Type, ie. Content-Type: multipart/form-data; ... will be allowed, excluding missing or empty Content-Type headers. Only valid Content-Type would result in binding parameters from form

Steps To Reproduce

No response

Exceptions (if any)

No response

.NET Version

8.0.101

Anything else?

Checked this issue: #39430 but didn't find this explicitly.

I am happy to contribute, but first would need confirmation that this is indeed a bug and not a design decision I am unaware of 😃

[davidfowl]

We should return 400 if the form isn't a valid content type rather than throwing (as part of the minimal API codegen).

[balazsmeszegeto]

We should return 400 if the form isn't a valid content type rather than throwing (as part of the minimal API codegen).

Just to make it clear, you mean 400, not 415? Because non-empty but invalid already returns 415. Should missing/empty be treated differently?

[davidfowl]

Actually, now I'm wondering why this isn't working:

aspnetcore/src/Http/Http.Extensions/src/RequestDelegateFactory.cs

Lines 1487 to 1492 in de12f70

	if (!httpContext.Request.HasFormContentType)
	{
	Log.UnexpectedNonFormContentType(httpContext, httpContext.Request.ContentType, throwOnBadRequest);
	httpContext.Response.StatusCode = StatusCodes.Status415UnsupportedMediaType;
	return (null, false);
	}

[balazsmeszegeto]

Actually, now I'm wondering why this isn't working:

aspnetcore/src/Http/Http.Extensions/src/RequestDelegateFactory.cs

Lines 1487 to 1492 in de12f70

	if (!httpContext.Request.HasFormContentType)
	{
	Log.UnexpectedNonFormContentType(httpContext, httpContext.Request.ContentType, throwOnBadRequest);
	httpContext.Response.StatusCode = StatusCodes.Status415UnsupportedMediaType;
	return (null, false);
	}

I don't think that's being used here, since it'd also accept Content-Type: application/x-www-form-urlencoded. But if I try

curl --request POST 'http://localhost:5000/upload' --header 'Content-Type: application/x-www-form-urlencoded'

so I get 415, as expected.

[balazsmeszegeto]

Update: the exception only happens if both of these are true:

• no request body
• Content-Type header is missing or empty

I've updated the issue's title.

The bug is in TryReadFormAsync, which would return successful if IHttpRequestBodyDetectionFeature.CanHaveBody is false. I've added a PR fixing it

aspnetcore/src/Http/Http.Extensions/src/RequestDelegateFactory.cs

Line 1478 in de12f70

if (feature?.CanHaveBody == true)