Remove default buffering for request form bodies

[Tratcher]

Does HttpRequest.Form really need to buffer the full request body? There's no mechanical requirement for it, the parser works just fine on streamed input. Once parsed the form contents are cached. The only reason you'd need access to the raw body again later is if some other library wanted to reparse it in their own way (e.g. Nancy), but you could enable buffering independently for those scenarios.

@lodejard @rynowak

[rynowak]

I don't recall the reason why this was done - but I'm also not aware of a need for this in MVC.

[Tratcher]

I think it was a precaution carried over from Katana where we knew we weren't the primary object model and components like OIDC always read other people's form requests.

I think we can make it opt-in via buffering middleware. Right now you can't opt-out without parsing the form yourself.

[davidfowl]

Let's not reintroduce the madness that ended up in System.Web: bufferless, buffered and inputstream. Can you write a sample on what opting in would look like?

[lodejard]

app.UseRequestBuffering() or whatever name makes sense. Would no-op if request.body.canseek is true.

Biggest reason would be needed is if middleware pokes around in form content.

Hmm... Something we could consider if we wanted to be kind... What if reading the form via the HttpRequest, if the body's CanSeek is false, then the request body can be replaced with one that throws invalid operation for subsequent read operations?

Specifically with error text like "Request body already fully parsed by HttpRequest.Form. Put app.UseBlahBlah() in your startup class to enable request stream buffering"

[Tratcher]

That's oddly specific, why would you do that kind of poisoning just for forms? We've gone out of our way to avoid exceptions in the request and response streams so far.

[lodejard]

Oddly specific? Form is the only thing in the default stack that will read the request body. One out of one is both oddly specific and universally consistent. :)