Still send 100 Continue given null MinRequestBodyDataRate

[halter73]

Description

This fixes a bug in Kestrel where a non-default configuration MinRequestBodyDataRate = null causes Kestrel not to send a "100 Continue" response given a "Expect: 100-continue" request header.

Customer impact

This was found (and eventually debugged) by an internal customer.

I am trying to migrate our code base from using Kestrel 2.2 (PackageReference 2.2.0 running on runtime 3.1.12) to Kestrel 3.1 (FrameworkReference onto Kestrel 3.1 with Runtime 3.1.12).
When running our performance tests, we saw a dramatic reduction in throughput, increase in latency and a precipitous drop in CPU – overall reduction in performance for POST workloads
...
If I measure the Stopwatch time to do a 0-byte read of the request body in the beginning of application (server) middleware code, the 2.2 code takes around 3ms, while the 3.1 code takes 15-20ms.

And it was also reported externally: #21502.

This shows up as a performance regression rather than failed request because clients will eventually start uploading the request body without a "100 Continue" response from Kestrel, but it will wait for a timeout causing increased latency.

Not all clients use "Expect: 100-continue" request header, but older .NET Framework clients do.

Regresssion

Yes. This was a regression introduced in 3.0.

Risk

Low. MinRequestBodyDataRate should have never had any impact on whether or not Kestrel sends a "100 Continue" response.

Fixes #30449

[ghost]

Hello human! Please make sure you've included the Shiproom Template in a comment or (preferably) the PR description. Also, make sure this PR is not marked as a draft and is ready-to-merge.

[Pilchie]

@halter73 / @davidfowl can one of you fill out the Ask Mode template so we can talk about this at Tactics today?

[halter73]

@Pilchie I've updated the description.

[Pilchie]

Thanks - we missed Tactics this morning, but we'll talk about it on Tuesday.

[Pilchie]

@halter73 any chance we get get the internal customer to verify the fix with a private before we merge, or at least before we ship?

Also, do we need a port of this to 5.0?

[halter73]

I asked the customer if they can verify the fix and cc'd you to the thread @Pilchie. And I opened the 5.0 PR at #31568.