MinRequestBodyDataRate is a Kestrel limit that times out a connection when request body data arrives slower than a minimum rate, measured in bytes per second, after a grace period. MinResponseDataRate does the same for responses. They defend against clients that send data very slowly to hold connections open.
How it works
The Microsoft documentation says Kestrel checks every second whether data is arriving at the specified rate. If the rate drops below the minimum, the connection times out. The grace period is the time Kestrel allows the client to raise its send rate up to the minimum. The rate is not checked during that period, which avoids dropping connections that start slowly because of TCP slow start. A minimum rate also applies to the response.
The ASP.NET Core 5.0 version of the page states a default minimum of 240 bytes per second with a 5 second grace period. Newer pages show only examples, so confirm the value for your version before relying on it.
Setting it
builder.WebHost.ConfigureKestrel(o =>
{
o.Limits.MinRequestBodyDataRate =
new MinDataRate(bytesPerSecond: 100, gracePeriod: TimeSpan.FromSeconds(10));
o.Limits.MinResponseDataRate =
new MinDataRate(bytesPerSecond: 100, gracePeriod: TimeSpan.FromSeconds(10));
});
You can also change the rate for one request from middleware through IHttpMinRequestBodyDataRateFeature and IHttpMinResponseDataRateFeature. Set it to null to turn the check off for a route, for example a very slow upload endpoint on a trusted network.
Things the docs call out
| Behaviour | Detail |
|---|---|
| HTTP/2 | The response rate feature is not present for HTTP/2 requests. The request body rate feature exists, but reading it or setting a value other than null throws NotSupportedException |
| Server wide limits | Limits on KestrelServerOptions.Limits still apply to both HTTP/1.x and HTTP/2 |
| Debugger | The data rate limits are not enforced while a debugger is attached |
Per request tuning is therefore mainly an HTTP/1.x tool. For HTTP/2 you may only disable the read rate check for a request, so decide the server wide value with care.
Trade offs
A higher minimum rate drops slow attackers sooner, but it also drops legitimate clients on poor mobile networks or satellite links. A lower minimum is kinder to those users and lets slow connections hold resources longer. There is no universal number. Look at the slowest real client you must support, such as an upload from a weak connection, and set the minimum below that.
Combine with other limits
A minimum data rate does not cap total size or total time. Use it with:
- A body size limit. See Kestrel limits to set.
- A headers timeout.
- Rate limiting per client.
- Edge or proxy protections for volumetric attacks. Microsoft's own rate limiting page states that rate limiting is not a comprehensive solution for distributed denial of service attacks.
Steps
- Record the current effective values in each environment.
- Decide a minimum that your slowest valid client meets.
- Set it in code, and override per route only where needed.
- Test with a client that throttles its upload below the minimum, with no debugger attached.
- Watch for timeouts in logs after release and adjust.
Try it yourself
Click through it at your own pace, or open it full screen. See how a scan probes a running web app from outside.
Quick check
Does this stop a DDoS?
No. It targets slow connections from a client. Large volume attacks need protection at the network edge.
Why did my slow upload fail only in production?
Debugger sessions skip the check, and local networks are fast. Test limits against a deployed build with a throttled client.
Safeguard dependency scanning and SBOM generation cover the NuGet packages in your ASP.NET Core service, and the free scan is at gold.safeguard.sh/scan.
Sources
- Configure options for the ASP.NET Core Kestrel web server (Microsoft Learn)
- Rate limiting middleware in ASP.NET Core (Microsoft Learn)
Last reviewed: 19 October 2026.