Please make sure to fill in the template before putting servicing-consider on (I'll put it in a wiki page or something):

#### Description

<!-- Describe the bug and the fix. -->

#### Customer Impact

<!--
* Was the bug reported by a customer?
* How does the bug impact the customer
* Are there any workarounds? If so, why are they not acceptable alternatives?
-->

#### Regression?

<!-- Either "no", or include the version that regressed the behavior -->

#### Risk

<!-- Describe the risk of introducing this change. -->

Description

Prior to this fix, when FormPipeReader.ReadFormAsync() threw due to some limit being exceeded, it would not call PipeReader.AdvanceTo() which can leave the request body pipe in an unusable state. This can interfere with Kestrel's ability to process the next request on the connection causing Kestrel to abruptly close the connection. We should also consider changes to Kestrel to improve resiliency against this across requests, but this is the simpler fix.

Customer Impact

• Was the bug reported by a customer?
  • The bug was reported by a customer at ReadFormAsync continues reading after exception #17723
• How does the bug impact the customer?
  • "This problem causes the connection to our proxy to break, which the proxy interprets as 500."
• Are there any workarounds? If so, why are they not acceptable alternatives?
  • Catching the exception and setting the "Connection: close" header might work around the issue, but this hasn't been tested with the proxy in question, and would hurt performance since the proxy would need to establish a new connection each time this happens.

Regression?

Yes. This bug did not exist prior to 3.0.

In 3.0, we started using FormPipeReader instead of the Stream-based FormReader from the FormFeature.

Risk

Very minimal. It's catching and rethrowing an exception after putting the request body Pipe back in a readable state.

Thanks @halter73 !