Support binding request body as Stream in Controller Actions

[brunolins16]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

The #38153 introduced the support for binding Stream/PipeReader, since it is common pattern a similar support must be available in Controller Actions.

Describe the solution you'd like

I would like to replicate the same code I have for a Minimal APIs:

app.MapPost("v1/feeds", async (QueueClient queueClient, Stream body, CancellationToken cancellationToken) =>
{
    await queueClient.CreateIfNotExistsAsync(cancellationToken: cancellationToken);
    await queueClient.SendMessageAsync(await BinaryData.FromStreamAsync(body), cancellationToken: cancellationToken);
});

I my Controller Actions:

[Route("v1/feeds")]
[ApiController]
public class FeedsController : ControllerBase
{
    [HttpPost]
    public async Task<ActionResult> Post(QueueClient queueClient, Stream body, CancellationToken cancellationToken)
    {
        await queueClient.CreateIfNotExistsAsync(cancellationToken: cancellationToken);
        await queueClient.SendMessageAsync(await BinaryData.FromStreamAsync(body), cancellationToken: cancellationToken);
        return Created("[somelocation]", null);
    }
}

I should also be able to explicitly define the parameter [FromBody] Stream body and must have the same behavior.

Additional context

The same considerations applied to Minimal should be applied here as well:

• When ingesting data, the Stream will be the same object as HttpRequest.Body.
• The request body isn’t buffered by default. After the body is read, it’s not rewindable (you can’t read the stream multiple times).
• The Stream/PipeReader are not usable outside of the controller action handler as the underlying buffers will be disposed and/or reused.

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.